Review Request: KMainWindow::parseGeometry() fails to position with positive coordinates

[Urban Widmark]

> On June 6, 2011, 2:04 a.m., David Faure wrote:
> > Looks good overall, but I think I found a bug with negative coordinates:
> > konqueror --geometry +500-100
> > gives me a window that xwininfo says is at "744x533+500-29", which doesn't match.
> > 
> > I have no experience with this, but it seems to me that negative values are "the distance between the bottom of the window and the bottom of the desktop", while the code is trying to use that for the topleft corner of the window instead (i.e. distance between top of window and bottom of desktop)?
> > When I increase the negative value (e.g. -150) nothing happens, then when I use -300 the window starts moving up.

For negative positions it uses the window size to calculate the new window position. Y coordinate of -100 becomes desktop height - 100 - window height.

The problem is that parseGeometry() is called from KMainWindowPrivate::init() before the application has had a chance to set a window size so the function will use a default size (I believe it is 640x480) if no size is given in the geometry string. So if the window is resized before shown you need to include that difference in the negative offset. Don't know about -29 (panel on the bottom and konqueror does not want to cover it?) or why you need to use as much as -300 to make the window move (konqueror initially sets the height to an even larger value?).

This problem is listed under "Testing Done" (a bit cryptic I guess). The same behaviour exists before the patch, and seems more complicated to solve. When is an application supposed to have decided the window size it wants?


Another option would be if QT understood negative window positions and could update as the window resizes... when googling for what qt does I stumbled on this patch to QTs handling of geometry:
http://qt.gitorious.org/qt/qt/merge_requests/2623

If QT is doing geometry parsing should KDE use that instead of doing its own? That one is in QApplication and not QMainWindow though.

That patch uses XSetWMNormalHints() to change how the window should grow. If resizing a window listens to those hints then that could fix negative positions. I'll have a look at that.


- Urban


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


On June 3, 2011, 10:09 p.m., Urban Widmark wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101492/
> -----------------------------------------------------------
> 
> (Updated June 3, 2011, 10:09 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> -------
> 
> 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, but the w/h variables will be used uninitialized unless both a size and position are given.
> 
> 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).
> 
> 
> Diffs
> -----
> 
>   kdeui/widgets/kmainwindow.cpp 1d27722 
> 
> Diff: http://git.reviewboard.kde.org/r/101492/diff
> 
> 
> Testing
> -------
> 
> 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
> keditbookmarks --geometry -400-300
> 
> 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.
> Negative positions also has a problem that parseGeometry(false) is called before keditbookmarks has set a (default) size on the window, so it is 640x480.
> 
> 
> Thanks,
> 
> Urban
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110606/cd18c859/attachment.htm>