[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: "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-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