QLineEdit issue

269 views
Skip to first unread message

Krzysztoff7

unread,
Oct 19, 2012, 9:39:24 AM10/19/12
to andro...@googlegroups.com
Android 4.0.4
Necessitas alpha 4 (27 Aug 2012) 
phone: se neo v, standard keyboard

There is a strange bug which I dont think it was in previous versions of necessitas. QLineEdit doesnt work properly. If inputMethodHints is set to ImhNone, everything that what I'm typing is Uppercase. If predictiveText is set to true, I need to confirm prompted word at the end of sentence (by tapping on it). Otherwise these word wont appear in content of input->text() method. What is more i need to type space after first word manually, otherwise the second word will be joined with the first one and mixed in some way. If i set ImhPreferLowercase, all of those words that we will type manually, will be in uppercase.

Another problem appears when virtual keyboard shows yourself. When we type some sentence then hide keyboard by tapping outside, QLineEdit will be blocked in some way (cant re-edit sentence)

Could you advise me somehow ? btw QML is not a solution in my case.

Willy Gardiol

unread,
Oct 19, 2012, 10:35:59 AM10/19/12
to andro...@googlegroups.com

As it's been repeated many times, _ALL_ Qt input's widgets are broken
in the mobile world. More or less.

It's pointless to fix it since not even Nokia/Digia does support
widgets on mobile.

i had to subclass line edits and fix them...
--
Willy Gardiol
wi...@gardiol.org
www.gardiol.org
www.trackaway.org -> Track YOUR way the way you want!

tomasl

unread,
Oct 19, 2012, 3:03:27 PM10/19/12
to andro...@googlegroups.com
Hi Krystoff7, 

This seems to be related to the bug I filed here: https://bugs.kde.org/show_bug.cgi?id=307748

It's up to someone who has a setup for compiling Necessitas to test BogDans patch for https://bugs.kde.org/show_bug.cgi?id=307443 to see if this solves the other issue. 

TomasL

tomasl

unread,
Oct 19, 2012, 3:08:07 PM10/19/12
to andro...@googlegroups.com
I'm afraid I'll have to disagree with you here, Willy. Simple things as QLineEdits should definitely work with Necessitas, and should be fixed. I hope the community in general agrees with me here.. :)

Willy Gardiol

unread,
Oct 19, 2012, 3:53:01 PM10/19/12
to andro...@googlegroups.com

I agree with you it would be good if it's fixed...

but widgets are deprecetd on mobile platforms, this is not something
Necessitas related, but Qt upstream related. QML is the de-facto way to
go for UIs on mobile. Not that i like it too much, but that's the
direction. As you know, qt5 deprecates all qwidgets, while they will
still be supported on qt5, they will not be developed or improved.

And after developing with Qt on symbian since day0, i can definitely
tell you input qwidgets works just barely and with countless bugs and
quirks, they are a pain. I had opened quite a few bugs with nokia back
in the days, all closed as "qwidgets are not supported on mobile
platforms". On the Nokia N9 not even the phone skin was applied to
qwidgets making them all ugly and unusable.

QLineEdits are by far the best working ones and you already hit a bug
with them.
>> www.gardiol.org [1]
>> www.trackaway.org [2] -> Track YOUR way the way you want!
>
>
> Links:
> ------
> [1] http://www.gardiol.org
> [2] http://www.trackaway.org

Sebastian Diel

unread,
Oct 19, 2012, 9:16:47 PM10/19/12
to andro...@googlegroups.com
Hi,

Willy Gardiol wrote:
> As it's been repeated many times, _ALL_ Qt input's widgets are broken
> in the mobile world. More or less.
That bad? Oh :-(
That may be a major blow for my intentions.
> It's pointless to fix it since not even Nokia/Digia does support
> widgets on mobile.
> i had to subclass line edits and fix them...
That's a contradiction ;) *ducking and running*

Is it possible to share that code? Even if it may be a special solution
for your needs it might enlighten the path for the less gifted ;)

Best regards,

Sebastian


dipje

unread,
Oct 20, 2012, 5:20:42 AM10/20/12
to andro...@googlegroups.com
As you know, qt5 deprecates all qwidgets, while they will
still be supported on qt5, they will not be developed or improved. 

Give a source for this please, cause it's the exact opposite of what is being said by the Qt team time and time again 

Krzysztoff7

unread,
Oct 20, 2012, 8:06:32 AM10/20/12
to andro...@googlegroups.com
As i say QML isnt solution for me. But to be more accurate I have tested simple textInput object in QML. 
Result: the same behavior with standard android keyboard as in QLineEdit.

Konrad Rosenbaum

unread,
Oct 21, 2012, 4:45:40 AM10/21/12
to andro...@googlegroups.com
Hi,

On Friday 19 October 2012, Willy Gardiol wrote:
> but widgets are deprecetd on mobile platforms, this is not something
> Necessitas related, but Qt upstream related. QML is the de-facto way to
> go for UIs on mobile.

They are not exactly "deprecated", but they are not native to mobile. Hence
they do not work very well on mobile platforms.

> Not that i like it too much, but that's the
> direction. As you know, qt5 deprecates all qwidgets, while they will
> still be supported on qt5, they will not be developed or improved.

This is misleading: Widgets are considered "done". Meaning: they are a
stable and working API with very little development remaining necessary, but
vital to Qt. They are far from "deprecated".

In fact there are quite a few developers who believe that widgets can still
be improved and are actively working on them.


Konrad
signature.asc

Nalin Savara

unread,
Oct 21, 2012, 9:21:52 AM10/21/12
to andro...@googlegroups.com
quite well said Konrad.

And incidentally widgets are the main supported cross-platform way,
more than qml- thats what I noticed developing on bb10 that doesnt
support qtcreator or qt qck bt qml+cascades... And lets you compile
qtcreator gen gui code.

Regards,

Nalin

Willy Gardiol

unread,
Oct 22, 2012, 3:50:32 AM10/22/12
to andro...@googlegroups.com

I too like and use widgets only. And i have been very pissed by Nokia's
move toward QML only on mobile.

Yet, if upstream does not fix input widgets for mobile, it's quite
pointless to kepp working with them, on mobile.

KDE is moving toward QML in it's GUI... this means something i guess.
Reply all
Reply to author
Forward
0 new messages