> 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. > > Thomas Lübking wrote: > 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 ;-)
Little bit off-topic, so pardon me. I have just come across (again) our KDE Api site: http://api.kde.org 1) Search field on the left 2) "search term" placeholder 3) I can paste a text from the clipboard in there, and the placeholder still remains. I have not used the Plasma Components much, but I hope there are no such situations whatever the decision will be. :-) - Laszlo ----------------------------------------------------------- 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 > >
