<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/101492/">http://git.reviewboard.kde.org/r/101492/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On June 3rd, 2011, 7:58 p.m., <b>Dawit Alemayehu</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;">Looks good, however should the new if statements have an else that defaulted to previous behavior ? That is should not

  if ( !(m & XValue) )
      x = this->x();
  if ( !(m & YValue) )
      y = this->y();

be 

  x = (!(m & XValue)) ? this->x() : geometry.x();
  y = (!(m & YValue)) ? this->y() : geometry.y();

instead or using the else statement if you prefer ?
</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;">No, when the flags are set the x/y variables will have been set by XParseGeometry() to the users input. Use of geometry().x() in the original code is wrong.

Hmm, there is another bug in the original code. If you have XNegative set it will use the w value, without checking the WidthValue flag and without having initialized it to any default (eg a geometry string of "-400-300"). Will change it to always set defaults and to use the fact that XParseGeometry() does not change arguments that are not defined in the input string.</pre>
<br />








<p>- Urban</p>


<br />
<p>On June 3rd, 2011, 6:58 p.m., Urban Widmark 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 Urban Widmark.</div>


<p style="color: grey;"><i>Updated June 3, 2011, 6:58 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;">When an X geometry is given on the command line, parseGeometry() will, for positive positions, use geometry().x()/.y() instead of the x/y value parsed from the string. This causes positive positions to not work. For negative values the string values are used.

No direct bugs reported on this that I can find, but the odd position behavior is noted in some --geometry related bugs:
Comment #6, http://bugs.kde.org/show_bug.cgi?id=165355
http://bugs.kde.org/show_bug.cgi?id=230663


For the KMainWindow --geometry parsing to work for both size and position, the client application will have to call applyMainWindowSettings() or restoreWindowSize(). The parsing done by KMainWindowPrivate::init() will only set position. Not sure if that is good, as a user of the window I would expect it to use all of the --geometry data at the same time (either on creation or some later call).
</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;">Using a KApplication program with a KMainWindow that also calls applyMainWindowSettings (keditbookmarks), positions verified using xwininfo:
keditbookmarks --geometry 400x300+100+200
keditbookmarks --geometry 400x300-100+200
keditbookmarks --geometry 400x300+100-200
keditbookmarks --geometry 400x300-100+200
keditbookmarks --geometry 400x300
keditbookmarks --geometry +100+200

Without patch all +coords are replaced by 0.
Negative positions do not account for window decorations as the size of those are not known. I suspect the user will have to adjust for that in their input.</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/kmainwindow.cpp <span style="color: grey">(1d27722)</span></li>

</ul>

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




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








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