> On May 9, 2012, 6:30 p.m., Mark Gaiser wrote:
> > Ehh optional perhaps?
> > I've seen forms behave like this before and back then when i first saw it i
> > tried to delete the text.. Which obviously didn't happen. The text just
> > disappears as soon as i start typing. I kinda dislike that behavior. I
> > mean, there is a big fat blue focus border that has the purpose of telling
> > the user that the one with the blue border (style dependent) is the one
> > that currently has focus. The blinking cursor is yet another indication
> > that the field has focus. I think that is enough.
> >
> > Perhaps optional, but please not by default. This is just my opinion and i
> > don't maintain plasma components (nor anything in KDE for that matter).
> > You'd have to wait for a reply from some of the plasma component
> > maintainers to get a final word on this.
>
> Sebastian Kügler wrote:
> This just fixes a race condition, I don't quite understand your
> reservation, Mark?
>
> David Edmundson wrote:
> No it doesn't. Currently if you give an item focus you hide the
> placeholder text. In this patch it only hides placeholder text after you
> start typing.
>
> David Edmundson wrote:
> ^ That reply was at Sebastian where he says it's a fix, where it's
> actually a large visual change. (reviewboard doesn't really show that very
> well)
>
> Sebastian Kügler wrote:
> Funny, because I ran into this exact behaviour last night, and to make it
> work well, I had to resort to using a Timer which calls forceActiveFocus() on
> the TextArea, not quite intuitive either.
>
> Does anyone have a suggestion which satisfies both usecase without hacks?
>
> Sebastian Gottfried wrote:
> Using a timer to give a text field the focus sounds really strange in my
> ears.
>
> We could obviously extend the API of the text fields with a boolean
> property "showPlaceholderWhileFocused" and give the responsibility to decide
> on the wanted behaviour to the application developer. But at least me would
> prefer a consistent behaviour for all text fields.
>
> Mark Gaiser wrote:
> The behavior is consistent right now. The defacto "standard" on the
> internet right now for forms seems to be to have a placeholder text and
> remove the placeholder as soon as the field gets focus. However, lately there
> have been more sites that do keep the placeholder even while focused and only
> moves away if you start typing. Like for example the twitter login page
> (though that does make the placeholder text a bit more transparent when you
> have the focus).
>
> I think both options should be provided, but the default should be to
> remove the placeholder as soon as it gets focus.
>
> Yet again just my opinion.
>
> Mathias Kraus wrote:
> How about the following:
> - pre-focused text field shows the placeholder
> - if the user press any key (e.g. Esc, arrow keys, backspace) or starts
> typing, the placeholder disappears and does't appear again, even if the text
> field is empty
> - it the user clicks into a text field, the placeholder also disappears
> immediatelly
>
> Laszlo Papp wrote:
> I do not have too strong opinions about either way; just some additional
> data fwiw:
>
> 1) QLineEdit - clear for focus
> http://qt-project.org/doc/qt-4.8/qlineedit.html#placeholderText-prop
>
> 2) KLineEdit - most likely the same since there is no such an addition
> for KLineEdit, but inherits this from QLineEdit
>
> 3) Harmattan components: clear for typing
>
> 4) Symbian components:
> http://doc.qt.nokia.com/qt-components-symbian/qml-textfield.html#placeholderText-prop
>
> 5) Interesting that the following html practice shares the opinions as
> well:
>
> http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_input_placeholder
>
> On Linux with firefox, rekonq and so forth, it produces the behavior that
> the placeholder is gone for focus. On the contrary, the form keeps the
> placeholder until typing on Windows.
The reason for the "clear on focus" behavior is to not confuse the user about
the content as soon as the entry is focused ("about to be used")
The "legacy" way in this regard (pre-focused & hinting lineedits) was to also
prefill the lineedit with the hint and pre-select the entire text (especially
if you really just want some input here or assume a "Cancel" otherwise)
Maybe -and if an empty string is no valid entry- one could merge those - start
with the prefilled selection, remove it and show the hint when the focus is
lost w/o typing.
No idea whether this can be done in a purely declarative way, though.
As for changing the focus with a timer, ie. while the event chain is running -
a hack that would QTimer::singleShot(3, this, SLOT) to cross some queued init
code is one thing (not deterministic but may still do the job) - stuff like
QTimer::singleShot(5000, this, SLOT) to show the hint for some seconds and then
activate the linenedit means tricking the user (you could usually as well
QTimer::singleShot(randomTime, this, randomSlot) - good way to piss users ;-)
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104895/#review13617
-----------------------------------------------------------
On May 9, 2012, 4:53 p.m., Sebastian Gottfried wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104895/
> -----------------------------------------------------------
>
> (Updated May 9, 2012, 4:53 p.m.)
>
>
> Review request for KDE Runtime.
>
>
> Description
> -------
>
> Rationale: This allows the application to pre-focus a text field with a
> placeholder text for the user. In the version before this would have
> hidden the placeholder text and it may not have been obvious for user
> what he was expected to enter in the text field.
>
>
> Diffs
> -----
>
> plasma/declarativeimports/plasmacomponents/qml/TextArea.qml 2d9e89f
> plasma/declarativeimports/plasmacomponents/qml/TextField.qml 4ed15d9
>
> Diff: http://git.reviewboard.kde.org/r/104895/diff/
>
>
> Testing
> -------
>
> Used it in ktouch/next, works fine.
>
>
> Screenshots
> -----------
>
> Form in KTouch
> http://git.reviewboard.kde.org/r/104895/s/562/
>
>
> Thanks,
>
> Sebastian Gottfried
>
>
