> On Dec. 12, 2012, 7:43 p.m., Laszlo Papp wrote:
> > It did not get a ship it back then for the plasma components, but I would 
> > not like to block the rediscussion, just saying what happened earlier. :-)
> > 
> > https://git.reviewboard.kde.org/r/104895/
> 
> David Edmundson wrote:
>     One of the key arguments people had then was because it would have led to 
> seriously inconsistent behaviour between plasma components and the desktop. 
>     
>     Aurelien is fixing that by also proposing to patch KDE libs, which turns 
> my personal opinion from a definite "no" to something I'm happy with.
>
> 
> Laszlo Papp wrote:
>     At least, I do not see such a key argument personally in the previous 
> review comments. As for me, it seems that certain people would prefer one 
> way, and certain people would prefer the other way. So, it is a hard decision 
> to take in my opinion. Certain projects do this way, and certain do not.
>     
>     It will stay inconsistent with the QLineEdit based applications for 
> instance (I know one could bring different examples, too). I am not envy for 
> the decision maker. :-)
> 
> Aurélien Gâteau wrote:
>     I see more and more interfaces switching to keeping the placeholder when 
> the widget is focused. This behavior can now be found in:
>     - Firefox awesome bar
>     - Android input fields
>     - Facebook search and input fields
>     - Twitter login form (with a nice twist: opacity of placeholder reduces 
> when focused)
>     - Deezer search field
>     - Google+ input field
>     - Wikipedia search field
>     - forum.kde.org search field
>     
>     For the record, I also plan to file a patch against Qt to change the 
> behavior of QLineEdit.
> 
> Laszlo Papp wrote:
>     I would personally suggest you to propose this against Qt first, and see 
> the reaction from Marc, Gunnar et al, anyone relevant.
>     
>     We are not in a hurry after all with this as we have been using the state 
> of affair for a long time. ;-)

Qt 5 now also keeps placeholder text visible when QLineEdit is focused ( 
https://codereview.qt-project.org/#change,45326 ). Can this change go in?


- Aurélien


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107678/#review23366
-----------------------------------------------------------


On Dec. 12, 2012, 6:10 p.m., Aurélien Gâteau wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107678/
> -----------------------------------------------------------
> 
> (Updated Dec. 12, 2012, 6:10 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> -------
> 
> This patch changes the way KLineEdit and KTextEdit handle the clickMessage 
> property. The message remains visible when the widget is focused, as long as 
> no text has been typed in. This is useful when the widget is focused by 
> default, and also gives another opportunity to the user to read the message 
> before typing, removing the need for workarounds  like clicking in another 
> text entry to bring back the clickMessage.
> 
> I filed a similar review-request for Plasma components: 
> https://git.reviewboard.kde.org/r/107600/
> 
> 
> Diffs
> -----
> 
>   kdeui/widgets/klineedit.cpp d96c1c4 
>   kdeui/widgets/ktextedit.cpp dfaf5b8 
> 
> Diff: http://git.reviewboard.kde.org/r/107678/diff/
> 
> 
> Testing
> -------
> 
> Tested KLineEdit in Dolphin "add place" dialog and KDevelop. Tested KTextEdit 
> with Gwenview "description" image field.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Reply via email to