[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: "David Faure" <faure () kde ! org>
Date: 2016-01-05 7:58:05
Message-ID: 20160105075805.6499.20323 () mimi ! kde ! org
[Download RAW message or body]
--===============8861915477472663017==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On Dec. 17, 2015, 4: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").
> Martin Gräßlin 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
>
> 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.
I don't see what's OS- or WS- specific in this. Well, session management \
might be, but the simple save/restore when quitting and launching an app \
again, has the exact same issues everywhere (I wonder if we confused the \
two features in this discussion). Ending up with a different solution for \
X11 and Mac just because you guys disagree doesn't sound like a valid \
solution to me, unless there's a technical reason that I'm missing.
I'm surprised by "X makes that really hard as positions are not screen \
relative. Wayland will fix it." -- surely we can ask an X11 window in which \
screen it is and store the position screen-relative... but then, that \
doesn't really help either if that screen is not there when restoring, so \
I'm not sure how the magic wayland will fix everything in that respect.
René: I have to agree with Martin that half-working features are to be \
avoided, they are the source of unhappy users and never-ending bug reports.
- David
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
On Dec. 14, 2015, 4: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, 4: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
>
>
--===============8861915477472663017==
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, \
4:16 p.m. UTC, <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, 5:21 p.m. UTC, <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, 5:36 p.m. UTC, <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, 7:08 a.m. UTC, <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, 12:02 p.m. UTC, <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, 10:13 a.m. UTC, <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, 9:16 p.m. UTC, <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 19th, 2015, 11:08 p.m. UTC, <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, 10:01 a.m. UTC, <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, 9:11 a.m. UTC, <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, 11:57 a.m. UTC, <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, 2:24 p.m. UTC, <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, 2:33 p.m. UTC, <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, 3:14 p.m. UTC, <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, 4:33 p.m. UTC, <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, 5:06 p.m. UTC, <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, 7:26 p.m. UTC, <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, 8:52 p.m. UTC, <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>
<p>On January 5th, 2016, 6:48 a.m. UTC, <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;">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> </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;">I don't see what's OS- or WS- \
specific in this. Well, session management might be, but the simple \
save/restore when quitting and launching an app again, has the exact same \
issues everywhere (I wonder if we confused the two features in this \
discussion). Ending up with a different solution for X11 and Mac just \
because you guys disagree doesn't sound like a valid solution to me, unless \
there's a technical reason that I'm missing.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I'm surprised by "X makes that really hard as positions are not \
screen relative. Wayland will fix it." -- surely we can ask an X11 window \
in which screen it is and store the position screen-relative... but then, \
that doesn't really help either if that screen is not there when restoring, \
so I'm not sure how the magic wayland will fix everything in that \
respect.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">René: I have to agree with \
Martin that half-working features are to be avoided, they are the source of \
unhappy users and never-ending bug reports.</p></pre> <br />
<p>- David</p>
<br />
<p>On December 14th, 2015, 4:04 p.m. UTC, 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, 4: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>
--===============8861915477472663017==--
[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