<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="http://git.reviewboard.kde.org/r/107678/">http://git.reviewboard.kde.org/r/107678/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On December 12th, 2012, 6:43 p.m., <b>Laszlo Papp</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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/</pre>
 </blockquote>




 <p>On December 13th, 2012, 5 a.m., <b>David Edmundson</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.
</pre>
 </blockquote>





 <p>On December 13th, 2012, 6:20 a.m., <b>Laszlo Papp</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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. :-)</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
<br />








<p>- Aurélien</p>


<br />
<p>On December 12th, 2012, 5:10 p.m., Aurélien Gâteau wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for kdelibs.</div>
<div>By Aurélien Gâteau.</div>


<p style="color: grey;"><i>Updated Dec. 12, 2012, 5:10 p.m.</i></p>






<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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/</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Tested KLineEdit in Dolphin "add place" dialog and KDevelop. Tested KTextEdit with Gwenview "description" image field.</pre>
  </td>
 </tr>
</table>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>kdeui/widgets/klineedit.cpp <span style="color: grey">(d96c1c4)</span></li>

 <li>kdeui/widgets/ktextedit.cpp <span style="color: grey">(dfaf5b8)</span></li>

</ul>

<p><a href="http://git.reviewboard.kde.org/r/107678/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>