[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/S
From: René J.V. Bertin <rjvbertin () gmail ! com>
Date: 2015-12-17 17:36:29
Message-ID: 20151217173629.5237.22575 () mimi ! kde ! org
[Download RAW message or body]
--===============1826604584649803934==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > <https://git.reviewboard.kde.org/r/126324/diff/4/?file=422749#file422749line38>
> >
> > That doesn't match the method name. It's saveWindowSize, not saveWindowGeometry. \
> > It's highly unexpected that saveWindowSize saves the position.
> > If you want that: please introduce a new saveWindowGeometry method.
>
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue that it's \
> highly unexpected from a user viewpoint that only window size is saved and not \
> position. How often would it happen that a developer is "highly surprised" in a \
> *negative* way that window size AND position are restored on a platform where this \
> is the default behaviour?
> I have nothing against introducing a pair of new methods, but how is that supposed \
> to be done in transparent fashion? I do have a lot against a need to change all \
> dependent software to call those methods (maintenance burden and all that).
> Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry \
> everywhere, with a platform-specific interpretation of what exactly geometry \
> encompasses. Much less surprise there, just a bit more need to read the \
> documentation. Are these functions ever called intentionally outside of what I \
> suppose is a more or less automatic feature that takes care of restoring window, \
> erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods \
they'll replace the WindowSize variants on OS X or at least those will then use a \
different KConfig key to avoid conflicts. I'd also be dropping the MS Windows part \
of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long \
time. Where exactly is the surprise, that restore/saveWindowSize never did what the \
key they operate with suggests, or that they have always been using an inaptly named \
key? For me the answer is straightforward and based on what users will expect...
- René J.V.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
On Dec. 14, 2015, 5:04 p.m., René J.V. Bertin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> -----------------------------------------------------------
>
> (Updated Dec. 14, 2015, 5:04 p.m.)
>
>
> Review request for KDE Software on Mac OS X and KDE Frameworks.
>
>
> Repository: kconfig
>
>
> Description
> -------
>
> In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() \
> function saved and restored not only the size but also the position (i.e. the \
> geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that \
> functionality (and I suppose most modern WMs have the feature enabled by default?)
> Both arguments are moot on MS Windows and OS X, and on both platforms users expect \
> to see window positions restored as well as window size. On OS X there is also \
> little choice in the matter: most applications offer the geometry restore without \
> asking (IIRC it is the same on MS Windows).
> I would thus like to propose to port the platform-specific code that existed for MS \
> Windows (and for OS X as a MacPorts patch that apparently was never submitted \
> upstreams). I realise that this violates the message conveyed by the function names \
> but I would like to think that this is a case where function is more important.
> You may also notice that the Mac version does not store resolution-specific \
> settings. This happens to work best on OS X, where multi-screen support has been \
> present since the early nineties, and where window geometry is restored regardless \
> of the screen resolution (i.e. connect a different external screen with a different \
> resolution, and windows will reopen as they were on that screen, not with some \
> default geometry). I required I can update the comments in the header to reflect \
> this subtlety.
> Note that for optimal functionality a companion patch to `KMainWindow::event` is \
> required: ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
> {
> K_D(KMainWindow);
> switch (ev->type()) {
> -#ifdef Q_OS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
> case QEvent::Move:
> #endif
> case QEvent::Resize:
> ```
>
> This ensures that the window geometry save is performed also after a move (to \
> update the position) without requiring a dummy resizing operation. Do I need to \
> create a separate RR for this change or is it small enough that I can push it if \
> and when this RR is accepted?
>
> Diffs
> -----
>
> src/gui/kwindowconfig.h 48a8f3c
> src/gui/kwindowconfig.cpp d2f355c
>
> Diff: https://git.reviewboard.kde.org/r/126324/diff/
>
>
> Testing
> -------
>
> On OS X 10.6 through 10.9 with various KDElibs4 versions and now with Qt 5.5.1 and \
> frameworks 5.16.0 (and Kate as a test application). I presume that the MS Windows \
> code has been tested sufficiently in KDELibs4; I have only adapted it to Qt5 and \
> tested if it builds.
>
> Thanks,
>
> René J.V. Bertin
>
>
--===============1826604584649803934==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 \
solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> \
<tr> <td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/126324/">https://git.reviewboard.kde.org/r/126324/</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 17th, 2015, 5:16 p.m. CET, <b>Martin \
Gräßlin</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; \
border-collapse: collapse; margin: 2px padding: 2px;"> <thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; \
font-size: 9pt; padding: 4px 8px; text-align: left;"> <a \
href="https://git.reviewboard.kde.org/r/126324/diff/4/?file=422749#file422749line38" \
style="color: black; font-weight: bold; text-decoration: \
underline;">src/gui/kwindowconfig.h</a> <span style="font-weight: normal;">
(Diff revision 4)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">class \
QWindow;</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#e9eaa8" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2">37</font></th> <td bgcolor="#fdfebc" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="cm"> * global or \
application config file.</span></pre></td> <th bgcolor="#e9eaa8" style="border-left: \
1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font \
size="2">38</font></th> <td bgcolor="#fdfebc" width="50%"><pre style="font-size: \
8pt; line-height: 140%; margin: 0; "><span class="cm"> * global or application config \
file.<span class="hl"> On MS Windows and Mac OS X this also</span></span></pre></td> \
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2"></font></th> <td bgcolor="#c5ffc4" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td> <th \
bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid \
#C0C0C0;" align="right"><font size="2">39</font></th> <td bgcolor="#c5ffc4" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span \
class="cm"> * saves the window position.</span></pre></td> </tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">That \
doesn't match the method name. It's saveWindowSize, not saveWindowGeometry. It's \
highly unexpected that saveWindowSize saves the position.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">If \
you want that: please introduce a new saveWindowGeometry method.</p></pre> \
</blockquote>
<p>On December 17th, 2015, 6:21 p.m. CET, <b>René J.V. Bertin</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;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I was \
afraid someone was going to say that, which is why I tried to argue that it's highly \
unexpected from a user viewpoint that only window size is saved and not position. How \
often would it happen that a developer is "highly surprised" in a <em style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">negative</em> way that window size AND position are restored on a platform \
where this is the default behaviour?</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">I have nothing against \
introducing a pair of new methods, but how is that supposed to be done in transparent \
fashion? I do have a lot against a need to change all dependent software to call \
those methods (maintenance burden and all that).</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Counter proposal: replace save/restoreWindowSize with \
save/restoreWindowGeometry everywhere, with a platform-specific interpretation of \
what exactly geometry encompasses. Much less surprise there, just a bit more need to \
read the documentation. Are these functions ever called intentionally outside of what \
I suppose is a more or less automatic feature that takes care of restoring window, \
erm, layout (saving is clearly automatic).</p></pre> </blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Just to be clear: if I am going to introduce restore/saveWindowGeometry \
methods they'll replace the WindowSize variants on OS X or at least those will then \
use a different KConfig key to avoid conflicts. I'd also be dropping the MS Windows \
part of the patch (as this is not a decision I want to make for a platform I don't \
use).</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">But please consider this: that KConfig key has been \
called <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: \
normal;margin: 0;line-height: inherit;">geometry</code> for a long time. Where \
exactly is the surprise, that restore/saveWindowSize never did what the key they \
operate with suggests, or that they have always been using an inaptly named key? For \
me the answer is straightforward and based on what users will expect...</p></pre> <br \
/>
<p>- René J.V.</p>
<br />
<p>On December 14th, 2015, 5:04 p.m. CET, René J.V. Bertin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: \
1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; \
-webkit-border-radius: 6px;"> <tr>
<td>
<div>Review request for KDE Software on Mac OS X and KDE Frameworks.</div>
<div>By René J.V. Bertin.</div>
<p style="color: grey;"><i>Updated Dec. 14, 2015, 5:04 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kconfig
</div>
<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;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">In KDElibs4, the KMainWindow::saveWindowSize() and \
KMainWindow::restoreWindowSize() function saved and restored not only the size but \
also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and \
QWidget::restoreGeometry.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">2 main reasons for this (according to \
the comments):
- Under X11 restoring the position is tricky
- X11 has a window manager which might be considered responsible for that \
functionality (and I suppose most modern WMs have the feature enabled by \
default?)</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Both arguments are moot on MS Windows and OS X, and on \
both platforms users expect to see window positions restored as well as window size. \
On OS X there is also little choice in the matter: most applications offer the \
geometry restore without asking (IIRC it is the same on MS Windows).</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I would thus like to propose to port the platform-specific code that \
existed for MS Windows (and for OS X as a MacPorts patch that apparently was never \
submitted upstreams). I realise that this violates the message conveyed by the \
function names but I would like to think that this is a case where function is more \
important.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">You may also notice that the Mac version does not \
store resolution-specific settings. This happens to work best on OS X, where \
multi-screen support has been present since the early nineties, and where window \
geometry is restored regardless of the screen resolution (i.e. connect a different \
external screen with a different resolution, and windows will reopen as they were on \
that screen, not with some default geometry). I required I can update the comments in \
the header to reflect this subtlety.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Note that for optimal \
functionality a companion patch to <code style="text-rendering: inherit;color: \
#4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">KMainWindow::event</code> is required:</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;"><div \
class="codehilite" style="background: #f8f8f8"><pre style="line-height: 125%"><span \
style="color: #A00000">--- a/src/kmainwindow.cpp</span> <span style="color: \
#00A000">+++ b/src/kmainwindow.cpp</span> <span style="color: #800080; font-weight: \
bold">@@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)</span> {
K_D(KMainWindow);
switch (ev->type()) {
<span style="color: #A00000">-#ifdef Q_OS_WIN</span>
<span style="color: #00A000">+#if defined(Q_OS_WIN) || defined(Q_OS_OSX)</span>
case QEvent::Move:
#endif
case QEvent::Resize:
</pre></div>
</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">This ensures that the window geometry save is \
performed also after a move (to update the position) without requiring a dummy \
resizing operation. Do I need to create a separate RR for this change or is it small \
enough that I can push it if and when this RR is accepted?</p></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;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">On OS X 10.6 through 10.9 with various KDElibs4 \
versions and now with Qt 5.5.1 and frameworks 5.16.0 (and Kate as a test \
application). I presume that the MS Windows code has been tested sufficiently in \
KDELibs4; I have only adapted it to Qt5 and tested if it builds.</p></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>src/gui/kwindowconfig.h <span style="color: grey">(48a8f3c)</span></li>
<li>src/gui/kwindowconfig.cpp <span style="color: grey">(d2f355c)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/126324/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============1826604584649803934==--
[Attachment #3 (text/plain)]
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic