[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-mac
Subject: Re: [KDE/Mac] Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only s
From: Martin_Gräßlin <mgraesslin () kde ! org>
Date: 2016-01-05 6:48:26
Message-ID: 20160105064826.6499.3441 () mimi ! kde ! org
[Download RAW message or body]
--===============7487841872357301899==
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).
> René J.V. Bertin wrote:
> 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...
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to something changing the \
> semantics like that.
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no issue with \
> maintaining methods for saving and restoring only window size, for code that somehow requires \
> that. I'd guess that such code would probably enforce the intended window position itself \
> *after* restoring window size (because that operation *can* affect window position), but in \
> the end that's (indeed) up to the code's developers to decide.
> IOW, I'm perfectly willing to discuss a better solution in which the burden to ensure that \
> window save/restore works as "natively" as possible on each platform is shared. The best way \
> to do that is of course to have a single pair of methods that have platform-specific \
> implementations.
> As far as I'm concerned such a solution might even be prepared completely in KConfig/gui \
> before changes are made everywhere else to deploy that new solution. In that case I would for \
> instance run temporary local (MacPorts) patches that replace saveWindowSize/restoreWindowSize \
> with wrappers for saveWindowGeometry/restoreWindowGeometry.
> Side-observation: OS X (Cocoa) provides a `[NSWindow setFrameAutosaveName:]` method, i.e. it \
> avoids reference to specifics like size or geometry completely.
> That method also provides another thought that could be taken into consideration if it is \
> decided to evolve this part of the frameworks, something I'd be interested in collaborating \
> on. Currently, there is no support for saving and restoring multiple windows per application. \
> That may be more or less sufficient when applications always follow a MDI approach, but even \
> if they do that still doesn't make them applications that are active only in a single \
> instance. Example: KDevelop. One might expect that opening a given, pre-existing session \
> (collection of open projects) restores the main window geometry (size and/or position) that \
> used previously for that session, rather than the geometry used by whatever KDevelop session \
> was run last. On OS X that would be done with something like `[NSWindow \
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow representedFile]` \
> corresponds to `QWindow::filePath` (but AFAICS those are not coupled in Qt5).
> I already had a quick look, but realised I don't know if the KConfig mechanism has facilities \
> to handle cleanup of stale/obsolete key/value entries.
> David Faure wrote:
> Note that most apps use this via the higher-level KMainWindow::setAutoSaveSettings() anyway, \
> which is supposed to 'do the right thing'. So my suggestion is to fix things one level higher \
> - let saveWindowSize save only the window size, but update \
> KMainWindow::saveMainWindowSettings/restoreMainWindowSettings to also store geometry on \
> platforms (windowing systems, more precisely) where it makes sense to also store the position \
> (i.e. non-X11, as I understand it?)
> René: you are wrong about "no support for saving and restoring multiple windows per \
> application", that is definitely there, see the "groupName" argument to setAutoSaveSettings \
> or the KConfigGroup argument to KWindowConfig::saveWindowSize(). Different (types of) \
> mainwindows in the same application can use different config groups.
> René J.V. Bertin wrote:
> I just had a look: KMainWindow:setAutoSaveSettings() indeed leads to \
> `KMainWindow::saveMainWindowSettings()`, which still uses KWindowConfig::saveWindowSize(). So \
> you're proposing what, to add a call to save position too where appropriate, or to replace \
> saveWindowSize in those cases? It's a solution, but I don't really like the idea of fixing \
> things above the level where the actual work is being done. In my experience it's a great way \
> to get deja-vu kind of situations where you wonder why that fix you applied isn't working \
> anymore, only to find out that some bit of code you hadn't encountered before uses the lower \
> level directly.
>
> How many apps do *not* use KMainWindow, and how many libraries (frameworks) use KWindowConfig \
> directly to keep dependencies down.
> I have been wondering why in fact position isn't saved on X11 desktops too, as far as that is \
> not in fact the case? (position *is* restored when restoring the session state at login, at \
> least on my KDE4 desktop.)
> David Faure wrote:
> I propose to add a saveWindowPosition next to saveWindowSize, and to call both from \
> KMainWindow.
> To find out who uses KWindowConfig directly, use http://lxr.kde.org
>
> Position is restored on X11 because ksmserver+kwin takes care of it, which fits with "the \
> window manager takes care of position on X11". Both during session management and when \
> launching apps interactively.
> René J.V. Bertin wrote:
> X11 also allows providing hints to the WM, which is how position restore could have been made \
> optional IIRC.
> Is this really a question of X11 vs. the rest of the world, what about Wayland?
>
> Anyway, I don't like the idea of having to call several functions (and introduce a set of new \
> functions) if there is no reason those new functions will ever be used outside of \
> saveMainWindowSettings/restoreMainWindowSettings
> KXmlGui already links to QtWidgets, so there is no extra cost in allowing \
> saveMainWindowSettings/restoreMainWindowSettings to let QWidget::saveGeometry/restoreGeometry \
> handle all settings related to window size and position. Those are the functions designed to \
> work as properly as possible on all supported platforms.
> It's a pity that QWidget::restoreGeometry doesn't have an optional filter to select the \
> aspects to restore: that would be the most elegant option. Use a single function to save the \
> relevant information, and another single function with a platform-specific filter argument to \
> restore it.
> I presume that absence of such an option is why save/restoreMainWindowSettings don't call \
> QMainWindow::save/restoreState?
> PS: should I read `restoreMainWindowSettings` as "restore the main window settings" as \
> opposed to "restore the mainwindow settings" (`restoreMainwindowSettings`)?
> David Faure wrote:
> No clue about whether WMs on wayland handle window positioning. Well, in a way all windowing \
> systems including OSX and Windows do handle positioning of new windows, don't they? It's not \
> like all your windows and dialogs appear at (0,0) on OSX or Windows. I'm wondering if there's \
> really a difference here....
> If you had used LXR as I suggested you would have a much stronger argument against me ;) \
> http://lxr.kde.org/ident?_i=saveWindowSize&_remember=1 actually shows a huge list of code \
> that uses KConfigGui::saveWindowSize directly: for dialogs. I assume you would want dialog \
> positions to be stored also, on non-X11? In that case a KConfigGui::saveWindowGeometry would \
> indeed be better API to avoid having to call two methods in all these places.
> I didn't know about QByteArray QWidget::saveGeometry() (when I worked on this kmainwindow \
> code Qt 4.2 didn't exist yet). It has three problems though: 1) it's an ugly blob of binary \
> data, 2) it's most probably broken on OSX (look at the ifdef in the implementation), 3) it's \
> in QWidget rather than QWindow, so it's not the right solution for QML based windows.
> Please forget saveState/restoreState, that's an even bigger hammer (which includes the \
> position of toolbars and dockwidgets etc.), and also widget-only, even worse, \
> mainwindows-only.
> PS: it's called KMainWindow, hence the name restoreMainWindowSettings. It's the settings for \
> that instance of KMainWindow, there can be many instances. Don't read "main" as "the one and \
> only primary", that's not what the main in [QK]MainWindow means, it just means it's a window \
> with toolbars and statusbars.
> IMHO a good solution would be to contribute to Qt a QWindow::saveGeometry/restoreGeometry, \
> similar to the QWidget one but at the QWindow level (it makes more sense there, not only for \
> QML... who wants to save/restore the geometry of a checkbox....)
> A good fallback solution is a KConfigGui::saveWindowGeometry/restoreWindowGeometry.
>
> Martin: is there actually a problem with saving/restoring the position on X11? The WM does \
> clever auto-positioning for new windows, but if as a user I position some dialog on the right \
> side of the screen, and I find it there again next time, it's fine, right? If not then yeah, \
> the best solution is to not save position, and document that in saveWindowGeometry. I think \
> your objection was about *changing* semantics of existing methods, but this is now about the \
> semantics of a new method.
> René J.V. Bertin wrote:
> > It's not like all your windows and dialogs appear at (0,0) on OSX or Windows.
> > I'm wondering if there's really a difference here....
>
> I've asked myself the same thing. The difference is probably in how windows are positioned \
> initially (I don't know any way to configure it on OS X or MS Windows), and what happens when \
> a window is reopened. Another difference is how the window server/manager handles positioning \
> instructions. The lack of a default positioning choice is probably what makes it obey the \
> instructions on OS X/MS Windows, whereas an X11 window manager has to find a compromise \
> between its user setting and what an application requests.
> Note that OS X does have a cascading option in which windows are opened with a slight offset \
> w.r.t. each other, but that's an application, not a system-wide user choice.
> > If you had used LXR as I suggested you would have a much stronger argument against me ;)
>
> Actually I did and saw what you saw (or maybe I searched for restoreWindowSize). I suppose \
> didn't mention it because I didn't want to be accused of arguing too much?
> > I assume you would want dialog positions to be stored also, on non-X11?
>
> I'd say that for dialogs it's more important that they reopen on the screen they were last \
> used, but restoring position is probably the best way to achieve that without complexifying \
> the code unnecessarily.
> > [In that case] a KConfigGui::saveWindowGeometry would indeed be better API to avoid having \
> > to call two methods
>
> I'd argue that's always the case and that the most elegant solution would be using a \
> saveWindowGeometry() method combined with a restoreGeometry() that takes additional flags \
> that control what saved data are to be restored (with a platform-dependent default or a \
> platform-dependent "RestoreWhatsUsualHere" constant). The flags could also instruct if \
> position is to be restored "hard" or through a WMHint - I take it KWin supports those?
> QWidget::save/restoreGeometry:
> > 1) it's an ugly blob of binary data
> That'd be saved as base64 to avoid issues with binary. In a reimplementation we could easily \
> use a different method to generate a human-readable QByteArray. Parsing that might not be so \
> easy though?
> > 2) it's most probably broken on OSX (look at the ifdef in the implementation)
> I wondered about that, but in fact it works just fine as far as I've been able to check.
>
> > If not then yeah, the best solution is to not save position, and document that in \
> > saveWindowGeometry.
>
> Did I mention I think the choice should be at the moment of restoring the information? :)
> If anything that would have the advantage that information doesn't get lost, and can be \
> restored when the user changes a global preference (or changes from X11 to Wayland, presuming \
> Wayland restores position by default).
> Martin Gräßlin wrote:
> > is there actually a problem with saving/restoring the position on X11?
>
> of course! That's why it's not implemented. I consider it as a stupid idea to save the \
> position. And the reasoning probably also applies to OSX.
> > The WM does clever auto-positioning for new windows, but if as a user I position some \
> > dialog on the right side of the screen, and I find it there again next time, it's fine, \
> > right?
>
> On X11 the window specified position is used, if provided. ICCCM explicitly says that a WM \
> has to honor the position, so that's fine. The problem is with multiple screen. If I close a \
> window on external screen, then disconnect and open again, the window will be positioned \
> outside the viewable area. It's a window which cannot be interacted with. So no, please don't \
> store the position, bad idea! The same argument might also be relevant on OSX.
> As long as we cannot have the position relative to the connected screens it doesn't make \
> sense.
> Concerning Wayland: on Wayland windows don't know there absolute position.
>
> David Faure wrote:
> Isn't this just an argument for being careful when restoring position, to make sure it fits \
> within the available geometry? I thought there were stronger reasons against storing \
> position, not one that can be fixed with a few qMin/qMax calls.
> René J.V. Bertin wrote:
> The argument is moot in any case on OS X: windows are restored in such a way that you can \
> reposition them if their saved position cannot be restored exactly (And again, there is no \
> window manager nor a set of rules related to such a thing, but if anything, position restore \
> is the rule.) I'd also consider it a WM bug if it interprets the WMHints position without \
> taking the actual screen estate into account; the whole idea with WM hints is that the WM can \
> know better.
> David: you did take the fact into consideration that not all multi-monitor set-ups use \
> multiple identical monitors, right? IOW, checking against the rectangle defined by two \
> diagonally opposite corners of the spanned desktop doesn't necessarily catch all \
> opportunities to map a window off-screen.
> Martin Gräßlin wrote:
> > not one that can be fixed with a few qMin/qMax calls
>
> This is not fixable with qMin/qMax calls. If the window is not on the screen where it was \
> before it shouldn't have any position, so that it can be placed by the window manager. If we \
> only sanitize the position through qMin/qMax we end up with a window positioning at a worse \
> position than what the WM would have done. Now how do we know on which screen the window was \
> on? We don't, because X11 lacks that info. A window is not bound to an XRandR screen. We \
> would have to store quite some information in addition to the position. Like the complete \
> setup at that time, all modes, etc. etc. Whenever anything of that doesn't match, we would \
> have to fall back to not setting a position.
> Now that's quite some complex code to hack and impossible to test - XRandR based setups just \
> cannot be tested.
> David Faure wrote:
> OK, good points. But then my suggestion for a simple restore algorithm becomes:
> if (saved pos fits within current screens geometry)
> use saved pos
> else
> let WM do placement
>
> It still helps quite a lot for everyone with a consistent screen setup, doesn't it? [at least \
> at saving time; e.g. I never shutdown my laptop with the office monitor still attached to it, \
> I use suspend-to-ram when leaving the office].
> Martin Gräßlin wrote:
> that could still result in pretty weird results. Just because the position fits in doesn't \
> mean the window will fit. There are many corner cases and we have looked at it quite a bit in \
> KWin as we have the requests that we should be able to restore the position of windows when \
> screens changes. Long story short: we came to the conclusion that geometries only make sense \
> in relation to a particular screen and X makes that really hard as positions are not screen \
> relative. Wayland will fix it.
> René J.V. Bertin wrote:
> One should be careful with this kind of reasoning: just because it is impossible to satisfy \
> all demands and possible scenarii doesn't mean one can/should simply give up even for the \
> simple cases - and certainly not on other platforms where the situation is completely \
> different. The Mac OS has supported changeable resolutions and spanning desktops ever since \
> screens were introduced that supported more than a single resolution and later computers that \
> supported more than 1 monitor. I've been using multi-screen set-ups since my first Mac, a IIx \
> which got its 2nd monitor in '90 or '91. Yes, changing a composite desktop layout is a \
> nightmare when trying to do something sensible with windows. Mac OS (X) isn't perfect in that \
> domain: it will for instance resize windows if they don't fit on the screen (but only if \
> they're against the border). Very annoying, but you learn to live with it. In my opinion it's \
> always better than windows that open somewhere else every time they open. If things change \
> and you can restore windows like they were, fine. If not, maybe you can place them in a \
> position that is close enough so that the user still perceives it as the expected position \
> (as a long-time Mac user I am inevitably influenced by Apple's ideas about spatial memory in \
> UIs). It's not the end of the world if part of the window is off-screen because I'm reopening \
> it on a screen with a different size. It may surprise at first, but I don't think you should \
> underestimate the experience of users who get to work with multiple sets of (external) \
> monitors. It seems highly unlikely they'll be the kind of user who just cannot understand why \
> that window doesn't fit and restore exactly where they left it on some other screen.
> @David: I've done exactly the same, for years, alternating between 3 different externals, \
> where the only constant was the relative position of my laptop's screen w.r.t. (0,0) which \
> was always on the external. On OS X you can switch to the login screen before you disconnect \
> the external; that way the windows of your session stay put (and you can disconnect before \
> suspending the host, and reconnect after waking it again, IOW the screen change isn't done \
> "behind its back").
> One should be careful with this kind of reasoning: just because it is impossible to satisfy \
> all demands and possible scenarii doesn't mean one can/should simply give up even for the \
> simple cases
on the other hand one should also not ignore the feedback by the domain experts :-) On X11 I \
don't want that as I think that it does more harm than it provides benefits. If you want it for \
OSX: go for it. But please not on X11.
- Martin
-----------------------------------------------------------
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
>
>
--===============7487841872357301899==
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>
<p>On December 17th, 2015, 6:36 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;">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> </blockquote>
<p>On December 18th, 2015, 8:08 a.m. CET, <b>Martin Gräßlin</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 leave it to the maintainers. On \
API I maintain I would say no to something changing the semantics like that.</p></pre> \
</blockquote>
<p>On December 18th, 2015, 1:02 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;">As I just wrote in reply to a \
message from Valorie, I have absolutely no issue with maintaining methods for saving and \
restoring only window size, for code that somehow requires that. I'd guess that such code would \
probably enforce the intended window position itself <em style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;">after</em> restoring window size \
(because that operation <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">can</em> affect window position), but in the end that's (indeed) \
up to the code's developers to decide.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">IOW, I'm perfectly willing to discuss a better \
solution in which the burden to ensure that window save/restore works as "natively" as possible \
on each platform is shared. The best way to do that is of course to have a single pair of \
methods that have platform-specific implementations.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">As far as I'm concerned such a \
solution might even be prepared completely in KConfig/gui before changes are made everywhere \
else to deploy that new solution. In that case I would for instance run temporary local \
(MacPorts) patches that replace saveWindowSize/restoreWindowSize with wrappers for \
saveWindowGeometry/restoreWindowGeometry.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Side-observation: OS X (Cocoa) \
provides a <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: \
normal;margin: 0;line-height: inherit;">[NSWindow setFrameAutosaveName:]</code> method, i.e. it \
avoids reference to specifics like size or geometry completely.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">That method \
also provides another thought that could be taken into consideration if it is decided to evolve \
this part of the frameworks, something I'd be interested in collaborating on. Currently, there \
is no support for saving and restoring multiple windows per application. That may be more or \
less sufficient when applications always follow a MDI approach, but even if they do that still \
doesn't make them applications that are active only in a single instance. Example: KDevelop. \
One might expect that opening a given, pre-existing session (collection of open projects) \
restores the main window geometry (size and/or position) that used previously for that session, \
rather than the geometry used by whatever KDevelop session was run last. On OS X that would be \
done with something like <code style="text-rendering: inherit;color: #4444cc;padding: \
0;white-space: normal;margin: 0;line-height: inh erit;">[NSWindow setFrameautosaveName:[window \
representedFile]]</code>, where <code style="text-rendering: inherit;color: #4444cc;padding: \
0;white-space: normal;margin: 0;line-height: inherit;">[NSWindow representedFile]</code> \
corresponds to <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: \
normal;margin: 0;line-height: inherit;">QWindow::filePath</code> (but AFAICS those are not \
coupled in Qt5).</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I already had a quick look, but realised I don't know if the \
KConfig mechanism has facilities to handle cleanup of stale/obsolete key/value \
entries.</p></pre> </blockquote>
<p>On December 19th, 2015, 11:13 a.m. CET, <b>David Faure</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;">Note that most apps use this via \
the higher-level KMainWindow::setAutoSaveSettings() anyway, which is supposed to 'do the right \
thing'. So my suggestion is to fix things one level higher - let saveWindowSize save only the \
window size, but update KMainWindow::saveMainWindowSettings/restoreMainWindowSettings to also \
store geometry on platforms (windowing systems, more precisely) where it makes sense to also \
store the position (i.e. non-X11, as I understand it?)</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">René: you are wrong about "no \
support for saving and restoring multiple windows per application", that is definitely there, \
see the "groupName" argument to setAutoSaveSettings or the KConfigGroup argument to \
KWindowConfig::saveWindowSize(). Different (types of) mainwindows in the same application can \
use different config groups.</p></pre> </blockquote>
<p>On December 19th, 2015, 10:16 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 just had a look: \
KMainWindow:setAutoSaveSettings() indeed leads to <code style="text-rendering: inherit;color: \
#4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">KMainWindow::saveMainWindowSettings()</code>, which still uses \
KWindowConfig::saveWindowSize(). So you're proposing what, to add a call to save position too \
where appropriate, or to replace saveWindowSize in those cases? It's a solution, but I don't \
really like the idea of fixing things above the level where the actual work is being done. In \
my experience it's a great way to get deja-vu kind of situations where you wonder why that fix \
you applied isn't working anymore, only to find out that some bit of code you hadn't \
encountered before uses the lower level directly.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">How many apps do <em \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">not</em> use KMainWindow, and how many libraries (frameworks) use KWindowConfig \
directly to keep dependencies down.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">I have been wondering why in fact position isn't \
saved on X11 desktops too, as far as that is not in fact the case? (position <em \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">is</em> restored when restoring the session state at login, at least on my KDE4 \
desktop.)</p></pre> </blockquote>
<p>On December 20th, 2015, 12:08 a.m. CET, <b>David Faure</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 propose to add a \
saveWindowPosition next to saveWindowSize, and to call both from KMainWindow.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">To find out who uses KWindowConfig directly, use http://lxr.kde.org</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Position is restored on X11 because ksmserver+kwin takes care of it, which fits with \
"the window manager takes care of position on X11". Both during session management and when \
launching apps interactively.</p></pre> </blockquote>
<p>On December 20th, 2015, 11:01 a.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;">X11 also allows providing hints \
to the WM, which is how position restore could have been made optional IIRC.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Is this really a question of X11 vs. the rest of the world, what about Wayland?</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Anyway, I don't like the idea of having to call several functions (and introduce a \
set of new functions) if there is no reason those new functions will ever be used outside of \
saveMainWindowSettings/restoreMainWindowSettings</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">KXmlGui already links to \
QtWidgets, so there is no extra cost in allowing \
saveMainWindowSettings/restoreMainWindowSettings to let QWidget::saveGeometry/restoreGeometry \
handle all settings related to window size and position. Those are the functions designed to \
work as properly as possible on all supported platforms.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">It's a pity \
that QWidget::restoreGeometry doesn't have an optional filter to select the aspects to restore: \
that would be the most elegant option. Use a single function to save the relevant information, \
and another single function with a platform-specific filter argument to restore it.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I presume that absence of such an option is why save/restoreMainWindowSettings don't \
call QMainWindow::save/restoreState?</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">PS: should I read <code style="text-rendering: \
inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: \
inherit;">restoreMainWindowSettings</code> as "restore the main window settings" as opposed to \
"restore the mainwindow settings" (<code style="text-rendering: inherit;color: #4444cc;padding: \
0;white-space: normal;margin: 0;line-height: \
inherit;">restoreMainwindowSettings</code>)?</p></pre> </blockquote>
<p>On December 25th, 2015, 10:11 a.m. CET, <b>David Faure</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;">No clue about whether WMs on \
wayland handle window positioning. Well, in a way all windowing systems including OSX and \
Windows do handle positioning of new windows, don't they? It's not like all your windows and \
dialogs appear at (0,0) on OSX or Windows. I'm wondering if there's really a difference \
here....</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">If you had used LXR as I suggested you would have a much \
stronger argument against me ;) http://lxr.kde.org/ident?_i=saveWindowSize&_remember=1 \
actually shows a huge list of code that uses KConfigGui::saveWindowSize directly: for dialogs. \
I assume you would want dialog positions to be stored also, on non-X11? In that case a \
KConfigGui::saveWindowGeometry would indeed be better API to avoid having to call two methods \
in all these places.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I didn't know about QByteArray QWidget::saveGeometry() (when I \
worked on this kmainwindow code Qt 4.2 didn't exist yet). It has three problems though: 1) it's \
an ugly blob of binary data, 2) it's most probably broken on OSX (look at the ifdef in the \
implementation), 3) it's in QWidget rather than QWindow, so it's not the right solution for QML \
based windows.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Please forget saveState/restoreState, that's an even bigger \
hammer (which includes the position of toolbars and dockwidgets etc.), and also widget-only, \
even worse, mainwindows-only.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">PS: it's called KMainWindow, hence the name \
restoreMainWindowSettings. It's the settings for that instance of KMainWindow, there can be \
many instances. Don't read "main" as "the one and only primary", that's not what the main in \
[QK]MainWindow means, it just means it's a window with toolbars and statusbars.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">IMHO a good solution would be to contribute to Qt a \
QWindow::saveGeometry/restoreGeometry, similar to the QWidget one but at the QWindow level (it \
makes more sense there, not only for QML... who wants to save/restore the geometry of a \
checkbox....)</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">A good fallback solution is a \
KConfigGui::saveWindowGeometry/restoreWindowGeometry.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Martin: is there actually a \
problem with saving/restoring the position on X11? The WM does clever auto-positioning for new \
windows, but if as a user I position some dialog on the right side of the screen, and I find it \
there again next time, it's fine, right? If not then yeah, the best solution is to not save \
position, and document that in saveWindowGeometry. I think your objection was about <em \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">changing</em> semantics of existing methods, but this is now about the semantics of a \
new method.</p></pre> </blockquote>
<p>On December 25th, 2015, 12:57 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;"><blockquote style="text-rendering: \
inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 \
0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">It's not like all your windows and dialogs appear \
at (0,0) on OSX or Windows. I'm wondering if there's really a difference here....</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I've asked myself the same thing. The difference is probably in how windows are \
positioned initially (I don't know any way to configure it on OS X or MS Windows), and what \
happens when a window is reopened. Another difference is how the window server/manager handles \
positioning instructions. The lack of a default positioning choice is probably what makes it \
obey the instructions on OS X/MS Windows, whereas an X11 window manager has to find a \
compromise between its user setting and what an application requests.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Note that OS X \
does have a cascading option in which windows are opened with a slight offset w.r.t. each \
other, but that's an application, not a system-wide user choice.</p> <blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: \
normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">If you had used LXR as I \
suggested you would have a much stronger argument against me ;)</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Actually I did and saw what you saw (or maybe I searched for restoreWindowSize). I \
suppose didn't mention it because I didn't want to be accused of arguing too much?</p> \
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I assume you \
would want dialog positions to be stored also, on non-X11?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I'd say that for dialogs it's more important that they reopen on the screen they were \
last used, but restoring position is probably the best way to achieve that without \
complexifying the code unnecessarily.</p> <blockquote style="text-rendering: inherit;padding: 0 \
0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: \
inherit;"> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">[In that case] a KConfigGui::saveWindowGeometry would indeed be \
better API to avoid having to call two methods</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I'd argue that's always the case and that the most elegant solution would be using a \
saveWindowGeometry() method combined with a restoreGeometry() that takes additional flags that \
control what saved data are to be restored (with a platform-dependent default or a \
platform-dependent "RestoreWhatsUsualHere" constant). The flags could also instruct if position \
is to be restored "hard" or through a WMHint - I take it KWin supports those?</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">QWidget::save/restoreGeometry:</p> <blockquote style="text-rendering: \
inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 \
0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">1) it's an ugly blob of binary data That'd be \
saved as base64 to avoid issues with binary. In a reimplementation we could easily use a \
different method to generate a human-readable QByteArray. Parsing that might not be so easy \
though?</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">2) it's most probably broken on OSX (look at the ifdef in the \
implementation) I wondered about that, but in fact it works just fine as far as I've been able \
to check.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">If not then yeah, the best solution is to not save position, and \
document that in saveWindowGeometry.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Did I mention I think the choice should be at the moment of restoring the \
information? :) If anything that would have the advantage that information doesn't get lost, \
and can be restored when the user changes a global preference (or changes from X11 to Wayland, \
presuming Wayland restores position by default).</p></pre> </blockquote>
<p>On January 4th, 2016, 3:24 p.m. CET, <b>Martin Gräßlin</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;"><blockquote style="text-rendering: \
inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 \
0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">is there actually a problem with saving/restoring \
the position on X11?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">of course! That's why it's not implemented. I consider it as a stupid idea to save \
the position. And the reasoning probably also applies to OSX.</p> <blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: \
normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">The WM does clever \
auto-positioning for new windows, but if as a user I position some dialog on the right side of \
the screen, and I find it there again next time, it's fine, right?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">On X11 the window specified position is used, if provided. ICCCM explicitly says that \
a WM has to honor the position, so that's fine. The problem is with multiple screen. If I close \
a window on external screen, then disconnect and open again, the window will be positioned \
outside the viewable area. It's a window which cannot be interacted with. So no, please don't \
store the position, bad idea! The same argument might also be relevant on OSX.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">As long as we cannot have the position relative to the connected screens it doesn't \
make sense.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Concerning Wayland: on Wayland windows don't know there absolute \
position.</p></pre> </blockquote>
<p>On January 4th, 2016, 3:33 p.m. CET, <b>David Faure</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;">Isn't this just an argument for \
being careful when restoring position, to make sure it fits within the available geometry? I \
thought there were stronger reasons against storing position, not one that can be fixed with a \
few qMin/qMax calls.</p></pre> </blockquote>
<p>On January 4th, 2016, 4:14 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;">The argument is moot in any case \
on OS X: windows are restored in such a way that you can reposition them if their saved \
position cannot be restored exactly (And again, there is no window manager nor a set of rules \
related to such a thing, but if anything, position restore is the rule.) I'd also consider it a \
WM bug if it interprets the WMHints position without taking the actual screen estate into \
account; the whole idea with WM hints is that the WM can know better.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">David: you did \
take the fact into consideration that not all multi-monitor set-ups use multiple identical \
monitors, right? IOW, checking against the rectangle defined by two diagonally opposite corners \
of the spanned desktop doesn't necessarily catch all opportunities to map a window \
off-screen.</p></pre> </blockquote>
<p>On January 4th, 2016, 5:33 p.m. CET, <b>Martin Gräßlin</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;"><blockquote style="text-rendering: \
inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 \
0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">not one that can be fixed with a few qMin/qMax \
calls</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">This is not fixable with qMin/qMax calls. If the window is not on the screen where it \
was before it shouldn't have any position, so that it can be placed by the window manager. If \
we only sanitize the position through qMin/qMax we end up with a window positioning at a worse \
position than what the WM would have done. Now how do we know on which screen the window was \
on? We don't, because X11 lacks that info. A window is not bound to an XRandR screen. We would \
have to store quite some information in addition to the position. Like the complete setup at \
that time, all modes, etc. etc. Whenever anything of that doesn't match, we would have to fall \
back to not setting a position.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">Now that's quite some complex code to hack and \
impossible to test - XRandR based setups just cannot be tested.</p></pre> </blockquote>
<p>On January 4th, 2016, 6:06 p.m. CET, <b>David Faure</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;">OK, good points. But then my \
suggestion for a simple restore algorithm becomes: if (saved pos fits within current screens \
geometry) use saved pos
else
let WM do placement</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">It still helps quite a lot for everyone with a consistent screen setup, doesn't it? \
[at least at saving time; e.g. I never shutdown my laptop with the office monitor still \
attached to it, I use suspend-to-ram when leaving the office].</p></pre> </blockquote>
<p>On January 4th, 2016, 8:26 p.m. CET, <b>Martin Gräßlin</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;">that could still result in pretty \
weird results. Just because the position fits in doesn't mean the window will fit. There are \
many corner cases and we have looked at it quite a bit in KWin as we have the requests that we \
should be able to restore the position of windows when screens changes. Long story short: we \
came to the conclusion that geometries only make sense in relation to a particular screen and X \
makes that really hard as positions are not screen relative. Wayland will fix it.</p></pre> \
</blockquote>
<p>On January 4th, 2016, 9:52 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;">One should be careful with this \
kind of reasoning: just because it is impossible to satisfy all demands and possible scenarii \
doesn't mean one can/should simply give up even for the simple cases - and certainly not on \
other platforms where the situation is completely different. The Mac OS has supported \
changeable resolutions and spanning desktops ever since screens were introduced that supported \
more than a single resolution and later computers that supported more than 1 monitor. I've been \
using multi-screen set-ups since my first Mac, a IIx which got its 2nd monitor in '90 or '91. \
Yes, changing a composite desktop layout is a nightmare when trying to do something sensible \
with windows. Mac OS (X) isn't perfect in that domain: it will for instance re size windows if \
they don't fit on the screen (but only if they're against the border). Very annoying, but you \
learn to live with it. In my opinion it's always better than windows that open somewhere else \
every time they open. If things change and you can restore windows like they were, fine. If \
not, maybe you can place them in a position that is close enough so that the user still \
perceives it as the expected position (as a long-time Mac user I am inevitably influenced by \
Apple's ideas about spatial memory in UIs). It's not the end of the world if part of the window \
is off-screen because I'm reopening it on a screen with a different size. It may surprise at \
first, but I don't think you should underestimate the experience of users who get to work with \
multiple sets of (external) monitors. It seems highly unlikely they'll be the kind of user who \
just cannot understand why that window doesn't fit and restore exactly where they left it on \
some other screen.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">@David: I've done exactly the same, for years, alternating \
between 3 different externals, where the only constant was the relative position of my laptop's \
screen w.r.t. (0,0) which was always on the external. On OS X you can switch to the login \
screen before you disconnect the external; that way the windows of your session stay put (and \
you can disconnect before suspending the host, and reconnect after waking it again, IOW the \
screen change isn't done "behind its back").</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;"><blockquote style="text-rendering: \
inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 \
0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">One should be careful with this kind of \
reasoning: just because it is impossible to satisfy all demands and possible scenarii doesn't \
mean one can/should simply give up even for the simple cases</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">on the other hand one should also not ignore the feedback by the domain experts :-) \
On X11 I don't want that as I think that it does more harm than it provides benefits. If you \
want it for OSX: go for it. But please not on X11.</p></pre> <br />
<p>- Martin</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>
--===============7487841872357301899==--
[Attachment #3 (text/plain)]
_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic