Discussion:
[KDE/Mac] Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)
(too old to reply)
René J.V. Bertin
2015-12-12 21:17:17 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------

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.cpp d2f355c
src/gui/CMakeLists.txt 9663e09
src/gui/kwindowconfig.h 48a8f3c

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
René J.V. Bertin
2015-12-12 21:19:56 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------

(Updated Dec. 12, 2015, 10:19 p.m.)


Review request for KDE Software on Mac OS X and KDE Frameworks.


Changes
-------

oops, typo in a last-minute change.


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 (updated)
-----

src/gui/kwindowconfig.h 48a8f3c
src/gui/kwindowconfig.cpp d2f355c
src/gui/CMakeLists.txt 9663e09

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
René J.V. Bertin
2015-12-13 13:54:30 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------

(Updated Dec. 13, 2015, 2:54 p.m.)


Review request for KDE Software on Mac OS X and KDE Frameworks.


Changes
-------

A minor change that supports the QPA-dependency of the contents of QWidget.saveGeometry(). A small nod to the fact that Qt (still) supports multiple QPA plugins on OS X.


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 (updated)
-----

src/gui/CMakeLists.txt 9663e09
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
Martin Gräßlin
2015-12-14 06:53:47 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89447
-----------------------------------------------------------



src/gui/CMakeLists.txt (line 2)
<https://git.reviewboard.kde.org/r/126324/#comment61218>

this introduces a QtWidgets dependency and thus changes the integration level of the framework. I highly recommend to not go this way.

Looking at the code there is no reason for this. The usage of QDesktopWidget is not needed as QScreen provides the same. Similar one doesn't need the QWidget usage as QWindow is already there.


- Martin GrÀßlin
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 2:54 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
René J.V. Bertin
2015-12-14 09:37:17 UTC
Permalink
Post by René J.V. Bertin
src/gui/CMakeLists.txt, line 2
<https://git.reviewboard.kde.org/r/126324/diff/3/?file=421934#file421934line2>
this introduces a QtWidgets dependency and thus changes the integration level of the framework. I highly recommend to not go this way.
Looking at the code there is no reason for this. The usage of QDesktopWidget is not needed as QScreen provides the same. Similar one doesn't need the QWidget usage as QWindow is already there.
I'm all for reducing the number of dependencies, but haven't found another way to get at QWidget::saveGeometry and QWidget::restoreGeometry.
You're probably much more familiar with what those functions really save and restore, and thus to what extent they're essentially convenience functions here for something I could just as well access via QWindow::geometry or QWindow::frameGeometry. I'd have to figure out on my end which of the two I'd need to use because that'd be specific to OS X (knowing there is no QWindow::setFrameGeometry). I won't be able to test that on MS Windows though.

What integration level are you invoking? This dependency doesn't make kconfig a Tier 2 framework, does it? Is it so bad to add a dependency on Qt5Widgets to something that already depends on Qt5Gui?

A more fundamental question would be why this is in KConfig. One could argue that window size (and position) are not application configuration parameters when they're saved automatically; they're a reflection of application interface state (@). Maybe a subtle difference (and maybe a debate that was already held a long time ago), but doesn't this rather (or better) belong in KWindowSystem?

@) Off-topic, but like other state variables saved automatically it might even be wise to save them in a separate file so it's easier to reset state without doing a full "factory reset".


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89447
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 2:54 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
Boudhayan Gupta
2015-12-14 09:40:39 UTC
Permalink
Post by René J.V. Bertin
src/gui/CMakeLists.txt, line 2
<https://git.reviewboard.kde.org/r/126324/diff/3/?file=421934#file421934line2>
this introduces a QtWidgets dependency and thus changes the integration level of the framework. I highly recommend to not go this way.
Looking at the code there is no reason for this. The usage of QDesktopWidget is not needed as QScreen provides the same. Similar one doesn't need the QWidget usage as QWindow is already there.
I'm all for reducing the number of dependencies, but haven't found another way to get at QWidget::saveGeometry and QWidget::restoreGeometry.
You're probably much more familiar with what those functions really save and restore, and thus to what extent they're essentially convenience functions here for something I could just as well access via QWindow::geometry or QWindow::frameGeometry. I'd have to figure out on my end which of the two I'd need to use because that'd be specific to OS X (knowing there is no QWindow::setFrameGeometry). I won't be able to test that on MS Windows though.
What integration level are you invoking? This dependency doesn't make kconfig a Tier 2 framework, does it? Is it so bad to add a dependency on Qt5Widgets to something that already depends on Qt5Gui?
@) Off-topic, but like other state variables saved automatically it might even be wise to save them in a separate file so it's easier to reset state without doing a full "factory reset".
In Qt5, a dependency on QtWidgets is the difference between having to use a QGuiApplication (without) and QApplication (with). QtWidgets is a 20MB or so dependency, so in terms of library load times at runtime the difference is somewhat significant.


- Boudhayan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89447
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 7:24 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
René J.V. Bertin
2015-12-14 11:03:07 UTC
Permalink
Post by René J.V. Bertin
src/gui/CMakeLists.txt, line 2
<https://git.reviewboard.kde.org/r/126324/diff/3/?file=421934#file421934line2>
this introduces a QtWidgets dependency and thus changes the integration level of the framework. I highly recommend to not go this way.
Looking at the code there is no reason for this. The usage of QDesktopWidget is not needed as QScreen provides the same. Similar one doesn't need the QWidget usage as QWindow is already there.
I'm all for reducing the number of dependencies, but haven't found another way to get at QWidget::saveGeometry and QWidget::restoreGeometry.
You're probably much more familiar with what those functions really save and restore, and thus to what extent they're essentially convenience functions here for something I could just as well access via QWindow::geometry or QWindow::frameGeometry. I'd have to figure out on my end which of the two I'd need to use because that'd be specific to OS X (knowing there is no QWindow::setFrameGeometry). I won't be able to test that on MS Windows though.
What integration level are you invoking? This dependency doesn't make kconfig a Tier 2 framework, does it? Is it so bad to add a dependency on Qt5Widgets to something that already depends on Qt5Gui?
@) Off-topic, but like other state variables saved automatically it might even be wise to save them in a separate file so it's easier to reset state without doing a full "factory reset".
In Qt5, a dependency on QtWidgets is the difference between having to use a QGuiApplication (without) and QApplication (with). QtWidgets is a 20MB or so dependency, so in terms of library load times at runtime the difference is somewhat significant.
I'm sensitive to that kind of argument. Interesting btw; my OS X QtWidgets library is 8.6Mb (which should include debug info), but on Linux using the same script for installing Qt it is 97Mb (!). So there is indeed some reason to introduce the extra dependency only on platforms where it's needed, if it's needed.

But (something I cannot NOT ask in this context) : just how many applications are there that present a user interface without any need for QtWidgets in any of their dependencies?


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89447
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 2:54 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
Boudhayan Gupta
2015-12-14 11:08:16 UTC
Permalink
Post by René J.V. Bertin
src/gui/CMakeLists.txt, line 2
<https://git.reviewboard.kde.org/r/126324/diff/3/?file=421934#file421934line2>
this introduces a QtWidgets dependency and thus changes the integration level of the framework. I highly recommend to not go this way.
Looking at the code there is no reason for this. The usage of QDesktopWidget is not needed as QScreen provides the same. Similar one doesn't need the QWidget usage as QWindow is already there.
I'm all for reducing the number of dependencies, but haven't found another way to get at QWidget::saveGeometry and QWidget::restoreGeometry.
You're probably much more familiar with what those functions really save and restore, and thus to what extent they're essentially convenience functions here for something I could just as well access via QWindow::geometry or QWindow::frameGeometry. I'd have to figure out on my end which of the two I'd need to use because that'd be specific to OS X (knowing there is no QWindow::setFrameGeometry). I won't be able to test that on MS Windows though.
What integration level are you invoking? This dependency doesn't make kconfig a Tier 2 framework, does it? Is it so bad to add a dependency on Qt5Widgets to something that already depends on Qt5Gui?
@) Off-topic, but like other state variables saved automatically it might even be wise to save them in a separate file so it's easier to reset state without doing a full "factory reset".
In Qt5, a dependency on QtWidgets is the difference between having to use a QGuiApplication (without) and QApplication (with). QtWidgets is a 20MB or so dependency, so in terms of library load times at runtime the difference is somewhat significant.
I'm sensitive to that kind of argument. Interesting btw; my OS X QtWidgets library is 8.6Mb (which should include debug info), but on Linux using the same script for installing Qt it is 97Mb (!). So there is indeed some reason to introduce the extra dependency only on platforms where it's needed, if it's needed.
But (something I cannot NOT ask in this context) : just how many applications are there that present a user interface without any need for QtWidgets in any of their dependencies?
The idea is that you can write OpenGL apps without introducing the QtWidgets dependency, by using Qt's event loop and drawing on a QWindow. The KDE Frameworks follow this philosophy - because they're supposed to be used independently of KDE, the frameworks strive to minimise their dependency footprint.


- Boudhayan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89447
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 7:24 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
Marco Martin
2015-12-14 11:47:10 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89465
-----------------------------------------------------------



src/gui/CMakeLists.txt (line 22)
<https://git.reviewboard.kde.org/r/126324/#comment61227>

we really can't add a dependency to QWidgets here.
depending on qwidgets will make many potential interested project not able to use it


- Marco Martin
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 1:54 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
Alex Richardson
2015-12-14 12:21:50 UTC
Permalink
Post by René J.V. Bertin
src/gui/CMakeLists.txt, line 22
<https://git.reviewboard.kde.org/r/126324/diff/3/?file=421934#file421934line22>
we really can't add a dependency to QWidgets here.
depending on qwidgets will make many potential interested project not able to use it
Also shouldn't all that information be available using QScreen/QWindow? It doesn't seem to save much: http://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwidget.cpp.html#_ZNK7QWidget12saveGeometryEv


- Alex


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89465
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 1:54 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
René J.V. Bertin
2015-12-14 13:29:38 UTC
Permalink
Post by Alex Richardson
src/gui/CMakeLists.txt, line 22
<https://git.reviewboard.kde.org/r/126324/diff/3/?file=421934#file421934line22>
we really can't add a dependency to QWidgets here.
depending on qwidgets will make many potential interested project not able to use it
Also shouldn't all that information be available using QScreen/QWindow? It doesn't seem to save much: http://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwidget.cpp.html#_ZNK7QWidget12saveGeometryEv
Are you more or less inviting me to "clone" QWidget::saveGeometry? It *does* do more than simply saving frame position and window size (I have a working prototype that saves and restores just that, but I guess you'd want me to include maximised state and what else?)


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89465
-----------------------------------------------------------
Post by Alex Richardson
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 2:54 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
Boudhayan Gupta
2015-12-14 13:40:55 UTC
Permalink
Post by Alex Richardson
src/gui/CMakeLists.txt, line 22
<https://git.reviewboard.kde.org/r/126324/diff/3/?file=421934#file421934line22>
we really can't add a dependency to QWidgets here.
depending on qwidgets will make many potential interested project not able to use it
Also shouldn't all that information be available using QScreen/QWindow? It doesn't seem to save much: http://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwidget.cpp.html#_ZNK7QWidget12saveGeometryEv
Are you more or less inviting me to "clone" QWidget::saveGeometry? It *does* do more than simply saving frame position and window size (I have a working prototype that saves and restores just that, but I guess you'd want me to include maximised state and what else?)
Don't just lift code. See what it does and then implement it your own way. Licensing between Qt and KDE are incompatible (quote: code may not be copied from Qt into KDE Platform as Qt is LGPL 2.1 only which would prevent it being used under LGPL 3 - from https://techbase.kde.org/Policies/Licensing_Policy)


- Boudhayan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89465
-----------------------------------------------------------
Post by Alex Richardson
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 7:24 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
Boudhayan Gupta
2015-12-14 14:08:14 UTC
Permalink
Post by Alex Richardson
src/gui/CMakeLists.txt, line 22
<https://git.reviewboard.kde.org/r/126324/diff/3/?file=421934#file421934line22>
we really can't add a dependency to QWidgets here.
depending on qwidgets will make many potential interested project not able to use it
Also shouldn't all that information be available using QScreen/QWindow? It doesn't seem to save much: http://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwidget.cpp.html#_ZNK7QWidget12saveGeometryEv
Are you more or less inviting me to "clone" QWidget::saveGeometry? It *does* do more than simply saving frame position and window size (I have a working prototype that saves and restores just that, but I guess you'd want me to include maximised state and what else?)
Don't just lift code. See what it does and then implement it your own way. Licensing between Qt and KDE are incompatible (quote: code may not be copied from Qt into KDE Platform as Qt is LGPL 2.1 only which would prevent it being used under LGPL 3 - from https://techbase.kde.org/Policies/Licensing_Policy)
Actually, René, I think it would be prudent to at least try and push a patch upstream to Qt implementing the window geometry APIs on QWindow.


- Boudhayan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89465
-----------------------------------------------------------
Post by Alex Richardson
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 13, 2015, 7:24 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.
- 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.
```
--- 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)
#endif
```
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/CMakeLists.txt 9663e09
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
René J.V. Bertin
2015-12-14 16:04:16 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------

(Updated Dec. 14, 2015, 5:04 p.m.)


Review request for KDE Software on Mac OS X and KDE Frameworks.


Changes
-------

Version taking the various issues into account.
I've reimplemented the (IMHO) relevant bits of QWidget::saveGeometry and QWidget::restoreGeometry as a class, in hope it might be reusable.

This works to satisfaction on OS X, and hopefully will do so on MS Windows too.

Restoring window size *and* position without a dedicated function that handles both aspects is often tricky (and platform dependent). QWidget::restoreGeometry is much more complex and it is well possible that is better capable to handle all possible interactions between size and position. I suppose time will tell.


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 (updated)
-----

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
Martin Gräßlin
2015-12-17 16:16:37 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------



src/gui/kwindowconfig.h (lines 38 - 39)
<https://git.reviewboard.kde.org/r/126324/#comment61408>

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.


- Martin GrÀßlin
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2015-12-17 17:21:48 UTC
Permalink
Post by René J.V. Bertin
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.
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.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2015-12-17 17:36:29 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).

But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
Martin Gräßlin
2015-12-18 07:08:23 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2015-12-18 12:02:59 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
David Faure
2015-12-19 10:13:57 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
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.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2015-12-19 21:16:33 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
David Faure
2015-12-19 23:08:59 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
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.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2015-12-20 10:01:56 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
David Faure
2015-12-25 09:11:44 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
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.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2015-12-25 11:57:58 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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.
Post by René J.V. Bertin
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?
Post by René J.V. Bertin
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.
Post by René J.V. Bertin
[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?
Post by René J.V. Bertin
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?
Post by René J.V. Bertin
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.
Post by René J.V. Bertin
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).


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
Jaime Torres Amate
2015-12-25 12:36:17 UTC
Permalink
Hello,

This is just a warning to know if this patch has been tested in a two monitor environment in a laptop.
In a pyqt application I save and restore the size and position of the window (without additional checks), using:
settings.setValue("size", self.ui.size())
settings.setValue("pos", self.ui.pos()) # save
----
self.ui.resize(settings.value("size", QSize(400, 400)))
self.ui.move(settings.value("pos", QPoint(200, 200))) # restore

It works perfectly fine except in this case:
The window, when saved, was in a monitor that disappears in the next run. In the next run (without the monitor) the window is not shown, because it is still in the other monitor, but it is shown in the taskbar, I have to go to the taskbar or with an advanced task manager, tell the window to become maximized, then it is shown.
If this patch shows the window when the monitor disappears, then, please, ignore this comment.


- Jaime Torres


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
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.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2015-12-25 13:33:18 UTC
Permalink
Post by Jaime Torres Amate
Hello,
This is just a warning to know if this patch has been tested in a two monitor environment in a laptop.
settings.setValue("size", self.ui.size())
settings.setValue("pos", self.ui.pos()) # save
----
self.ui.resize(settings.value("size", QSize(400, 400)))
self.ui.move(settings.value("pos", QPoint(200, 200))) # restore
The window, when saved, was in a monitor that disappears in the next run. In the next run (without the monitor) the window is not shown, because it is still in the other monitor, but it is shown in the taskbar, I have to go to the taskbar or with an advanced task manager, tell the window to become maximized, then it is shown.
If this patch shows the window when the monitor disappears, then, please, ignore this comment.
What OS/windowing environment is that?

To the best of my knowledge, OS X will rearrange windows when a monitor is disconnected (regardless whether on a laptop or desktop host) and should do the same when reopening a window in an offscreen position if that window isn't meant to be offscreen. I haven't yet tested this because of the rearranging thing, but good point. I'll see if it can be simulated by storing an offscreen position (this is where the binary nature of the saved data is annoying indeed!)


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by Jaime Torres Amate
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
Jaime Torres Amate
2015-12-25 16:13:50 UTC
Permalink
Post by Jaime Torres Amate
Hello,
This is just a warning to know if this patch has been tested in a two monitor environment in a laptop.
settings.setValue("size", self.ui.size())
settings.setValue("pos", self.ui.pos()) # save
----
self.ui.resize(settings.value("size", QSize(400, 400)))
self.ui.move(settings.value("pos", QPoint(200, 200))) # restore
The window, when saved, was in a monitor that disappears in the next run. In the next run (without the monitor) the window is not shown, because it is still in the other monitor, but it is shown in the taskbar, I have to go to the taskbar or with an advanced task manager, tell the window to become maximized, then it is shown.
If this patch shows the window when the monitor disappears, then, please, ignore this comment.
What OS/windowing environment is that?
To the best of my knowledge, OS X will rearrange windows when a monitor is disconnected (regardless whether on a laptop or desktop host) and should do the same when reopening a window in an offscreen position if that window isn't meant to be offscreen. I haven't yet tested this because of the rearranging thing, but good point. I'll see if it can be simulated by storing an offscreen position (this is where the binary nature of the saved data is annoying indeed!)
Oh!, I'm sorry, I forgot to say. It is a windows 7. It rearranges other windows, but as it's position is restored, it goes to the non connected monitor. I hope it does not happen with this patch (In linux it does not happen to that pyqt program).


- Jaime Torres


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by Jaime Torres Amate
-----------------------------------------------------------
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.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2015-12-25 16:45:15 UTC
Permalink
Post by Jaime Torres Amate
Hello,
This is just a warning to know if this patch has been tested in a two monitor environment in a laptop.
settings.setValue("size", self.ui.size())
settings.setValue("pos", self.ui.pos()) # save
----
self.ui.resize(settings.value("size", QSize(400, 400)))
self.ui.move(settings.value("pos", QPoint(200, 200))) # restore
The window, when saved, was in a monitor that disappears in the next run. In the next run (without the monitor) the window is not shown, because it is still in the other monitor, but it is shown in the taskbar, I have to go to the taskbar or with an advanced task manager, tell the window to become maximized, then it is shown.
If this patch shows the window when the monitor disappears, then, please, ignore this comment.
What OS/windowing environment is that?
To the best of my knowledge, OS X will rearrange windows when a monitor is disconnected (regardless whether on a laptop or desktop host) and should do the same when reopening a window in an offscreen position if that window isn't meant to be offscreen. I haven't yet tested this because of the rearranging thing, but good point. I'll see if it can be simulated by storing an offscreen position (this is where the binary nature of the saved data is annoying indeed!)
Oh!, I'm sorry, I forgot to say. It is a windows 7. It rearranges other windows, but as it's position is restored, it goes to the non connected monitor. I hope it does not happen with this patch (In linux it does not happen to that pyqt program).
Even if it doesn't on OS X, someone will have to test on MS Windows.

I presume one can obtain the limits within which the position has to lie and constrain the position so that at least part of the window is visible (even if those limits reflect only the rectangle within which the available screens lie).


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by Jaime Torres Amate
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2015-12-26 00:06:56 UTC
Permalink
Post by Jaime Torres Amate
Hello,
This is just a warning to know if this patch has been tested in a two monitor environment in a laptop.
settings.setValue("size", self.ui.size())
settings.setValue("pos", self.ui.pos()) # save
----
self.ui.resize(settings.value("size", QSize(400, 400)))
self.ui.move(settings.value("pos", QPoint(200, 200))) # restore
The window, when saved, was in a monitor that disappears in the next run. In the next run (without the monitor) the window is not shown, because it is still in the other monitor, but it is shown in the taskbar, I have to go to the taskbar or with an advanced task manager, tell the window to become maximized, then it is shown.
If this patch shows the window when the monitor disappears, then, please, ignore this comment.
What OS/windowing environment is that?
To the best of my knowledge, OS X will rearrange windows when a monitor is disconnected (regardless whether on a laptop or desktop host) and should do the same when reopening a window in an offscreen position if that window isn't meant to be offscreen. I haven't yet tested this because of the rearranging thing, but good point. I'll see if it can be simulated by storing an offscreen position (this is where the binary nature of the saved data is annoying indeed!)
Oh!, I'm sorry, I forgot to say. It is a windows 7. It rearranges other windows, but as it's position is restored, it goes to the non connected monitor. I hope it does not happen with this patch (In linux it does not happen to that pyqt program).
Even if it doesn't on OS X, someone will have to test on MS Windows.
I presume one can obtain the limits within which the position has to lie and constrain the position so that at least part of the window is visible (even if those limits reflect only the rectangle within which the available screens lie).
I just checked this, doing `frameGeo.adjust()` with a selection of huge values in `GeometryData::applyToWindow()`. As I thought, OS X doesn't allow you to open a regular window completely offscreen. The requested position is altered such that there's always just enough of it that remains visible and available for grabbing and moving it to a better position.

Jaime: do you know what `self.ui.pos()` resolves to, `QWindow::position()` or `QWindow::framePosition()`? I would not really surprise me if trying to set the former (through `setPosition()`) gives different results than using the latter (through `setFramePosition()`) in case of offscreen co-ordinates.


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by Jaime Torres Amate
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
Jaime Torres Amate
2015-12-26 09:17:43 UTC
Permalink
Post by Jaime Torres Amate
Hello,
This is just a warning to know if this patch has been tested in a two monitor environment in a laptop.
settings.setValue("size", self.ui.size())
settings.setValue("pos", self.ui.pos()) # save
----
self.ui.resize(settings.value("size", QSize(400, 400)))
self.ui.move(settings.value("pos", QPoint(200, 200))) # restore
The window, when saved, was in a monitor that disappears in the next run. In the next run (without the monitor) the window is not shown, because it is still in the other monitor, but it is shown in the taskbar, I have to go to the taskbar or with an advanced task manager, tell the window to become maximized, then it is shown.
If this patch shows the window when the monitor disappears, then, please, ignore this comment.
What OS/windowing environment is that?
To the best of my knowledge, OS X will rearrange windows when a monitor is disconnected (regardless whether on a laptop or desktop host) and should do the same when reopening a window in an offscreen position if that window isn't meant to be offscreen. I haven't yet tested this because of the rearranging thing, but good point. I'll see if it can be simulated by storing an offscreen position (this is where the binary nature of the saved data is annoying indeed!)
Oh!, I'm sorry, I forgot to say. It is a windows 7. It rearranges other windows, but as it's position is restored, it goes to the non connected monitor. I hope it does not happen with this patch (In linux it does not happen to that pyqt program).
Even if it doesn't on OS X, someone will have to test on MS Windows.
I presume one can obtain the limits within which the position has to lie and constrain the position so that at least part of the window is visible (even if those limits reflect only the rectangle within which the available screens lie).
I just checked this, doing `frameGeo.adjust()` with a selection of huge values in `GeometryData::applyToWindow()`. As I thought, OS X doesn't allow you to open a regular window completely offscreen. The requested position is altered such that there's always just enough of it that remains visible and available for grabbing and moving it to a better position.
Jaime: do you know what `self.ui.pos()` resolves to, `QWindow::position()` or `QWindow::framePosition()`? I would not really surprise me if trying to set the former (through `setPosition()`) gives different results than using the latter (through `setFramePosition()`) in case of offscreen co-ordinates.
Hi, the documentation here is lacking the description, but I guess it is position(), as there are other bindings for frameGeometry().
Thanks for checking it. I have no more objections.
Best regards.


- Jaime Torres


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by Jaime Torres Amate
-----------------------------------------------------------
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.
- 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.
```
--- 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)
#endif
```
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
Martin Gräßlin
2016-01-04 14:24:02 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
Post by René J.V. Bertin
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.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
David Faure
2016-01-04 14:33:22 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
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.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2016-01-04 15:14:29 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.
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.


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
Martin Gräßlin
2016-01-04 16:33:25 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.
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.
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.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
David Faure
2016-01-04 17:06:20 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.
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.
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.
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].


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
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.
- 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.
```
--- 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)
#endif
```
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
Martin Gräßlin
2016-01-04 19:26:40 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.
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.
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.
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].
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.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2016-01-04 20:52:56 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.
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.
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.
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].
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.
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").


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
Martin Gräßlin
2016-01-05 06:48:26 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.
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.
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.
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].
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.
One should be careful with this kind of reasoning: just because it is impossible to satisfy all demands and possible scenarii doesn't mean one can/should simply give up even for the simple cases - and certainly not on other platforms where the situation is completely different. The Mac OS has supported changeable resolutions and spanning desktops ever since screens were introduced that supported more than a single resolution and later computers that supported more than 1 monitor. I've been using multi-screen set-ups since my first Mac, a IIx which got its 2nd monitor in '90 or '91. Yes, changing a composite desktop layout is a nightmare when trying to do something sensible with windows. Mac OS (X) isn't perfect in that domain: it will for instance resize windows if they don't fit on the screen (but only if they're against the border). Very annoying, but you learn to live with it. In my opinion it's always better than windows that open somewhere else every time they open.
If things change and you can restore windows like they were, fine. If not, maybe you can place them in a position that is close enough so that the user still perceives it as the expected position (as a long-time Mac user I am inevitably influenced by Apple's ideas about spatial memory in UIs). It's not the end of the world if part of the window is off-screen because I'm reopening it on a screen with a different size. It may surprise at first, but I don't think you should underestimate the experience of users who get to work with multiple sets of (external) monitors. It seems highly unlikely they'll be the kind of user who just cannot understand why that window doesn't fit and restore exactly where they left it on some other screen.
@David: I've done exactly the same, for years, alternating between 3 different externals, where the only constant was the relative position of my laptop's screen w.r.t. (0,0) which was always on the external. On OS X you can switch to the login screen before you disconnect the external; that way the windows of your session stay put (and you can disconnect before suspending the host, and reconnect after waking it again, IOW the screen change isn't done "behind its back").
One should be careful with this kind of reasoning: just because it is impossible to satisfy all demands and possible scenarii doesn't mean one can/should simply give up even for the simple cases
on the other hand one should also not ignore the feedback by the domain experts :-) On X11 I don't want that as I think that it does more harm than it provides benefits. If you want it for OSX: go for it. But please not on X11.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
David Faure
2016-01-05 07:58:05 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.
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.
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.
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].
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.
One should be careful with this kind of reasoning: just because it is impossible to satisfy all demands and possible scenarii doesn't mean one can/should simply give up even for the simple cases - and certainly not on other platforms where the situation is completely different. The Mac OS has supported changeable resolutions and spanning desktops ever since screens were introduced that supported more than a single resolution and later computers that supported more than 1 monitor. I've been using multi-screen set-ups since my first Mac, a IIx which got its 2nd monitor in '90 or '91. Yes, changing a composite desktop layout is a nightmare when trying to do something sensible with windows. Mac OS (X) isn't perfect in that domain: it will for instance resize windows if they don't fit on the screen (but only if they're against the border). Very annoying, but you learn to live with it. In my opinion it's always better than windows that open somewhere else every time they open.
If things change and you can restore windows like they were, fine. If not, maybe you can place them in a position that is close enough so that the user still perceives it as the expected position (as a long-time Mac user I am inevitably influenced by Apple's ideas about spatial memory in UIs). It's not the end of the world if part of the window is off-screen because I'm reopening it on a screen with a different size. It may surprise at first, but I don't think you should underestimate the experience of users who get to work with multiple sets of (external) monitors. It seems highly unlikely they'll be the kind of user who just cannot understand why that window doesn't fit and restore exactly where they left it on some other screen.
@David: I've done exactly the same, for years, alternating between 3 different externals, where the only constant was the relative position of my laptop's screen w.r.t. (0,0) which was always on the external. On OS X you can switch to the login screen before you disconnect the external; that way the windows of your session stay put (and you can disconnect before suspending the host, and reconnect after waking it again, IOW the screen change isn't done "behind its back").
One should be careful with this kind of reasoning: just because it is impossible to satisfy all demands and possible scenarii doesn't mean one can/should simply give up even for the simple cases
on the other hand one should also not ignore the feedback by the domain experts :-) On X11 I don't want that as I think that it does more harm than it provides benefits. If you want it for OSX: go for it. But please not on X11.
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
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
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.
- 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.
```
--- 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)
#endif
```
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
René J.V. Bertin
2016-01-05 09:55:51 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.
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.
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.
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].
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.
One should be careful with this kind of reasoning: just because it is impossible to satisfy all demands and possible scenarii doesn't mean one can/should simply give up even for the simple cases - and certainly not on other platforms where the situation is completely different. The Mac OS has supported changeable resolutions and spanning desktops ever since screens were introduced that supported more than a single resolution and later computers that supported more than 1 monitor. I've been using multi-screen set-ups since my first Mac, a IIx which got its 2nd monitor in '90 or '91. Yes, changing a composite desktop layout is a nightmare when trying to do something sensible with windows. Mac OS (X) isn't perfect in that domain: it will for instance resize windows if they don't fit on the screen (but only if they're against the border). Very annoying, but you learn to live with it. In my opinion it's always better than windows that open somewhere else every time they open.
If things change and you can restore windows like they were, fine. If not, maybe you can place them in a position that is close enough so that the user still perceives it as the expected position (as a long-time Mac user I am inevitably influenced by Apple's ideas about spatial memory in UIs). It's not the end of the world if part of the window is off-screen because I'm reopening it on a screen with a different size. It may surprise at first, but I don't think you should underestimate the experience of users who get to work with multiple sets of (external) monitors. It seems highly unlikely they'll be the kind of user who just cannot understand why that window doesn't fit and restore exactly where they left it on some other screen.
@David: I've done exactly the same, for years, alternating between 3 different externals, where the only constant was the relative position of my laptop's screen w.r.t. (0,0) which was always on the external. On OS X you can switch to the login screen before you disconnect the external; that way the windows of your session stay put (and you can disconnect before suspending the host, and reconnect after waking it again, IOW the screen change isn't done "behind its back").
One should be careful with this kind of reasoning: just because it is impossible to satisfy all demands and possible scenarii doesn't mean one can/should simply give up even for the simple cases
on the other hand one should also not ignore the feedback by the domain experts :-) On X11 I don't want that as I think that it does more harm than it provides benefits. If you want it for OSX: go for it. But please not on X11.
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.
I'm not saying something like this has to be implemented for X11. I do think it'd be a valid approach to use WM hints for position and then leave it up to the WM what to do with the information (possibly depending on how the user configured that WM), but ultimately it is indeed up to domain experts to decide.
But: if KF5 wants to do things the Mac way, and that way is different from the X11 way, how can you not end up using a different solution?

As to half-baked features: do you think that applies to QWidget::save/restoreGeometry (regardless of whether we can use it here)? It's really a pity in that sense that KConfig has to be so lean in its dependencies.
Also, I have been noticing (and mildly annoyed about it) that certain of the windows on my KDE4 session are being restored to where I left them (my 2 vertically-maximised Konsole windows, and the ones from my Chrome session), but most others are not. Kontact tends to end up more or less in the right spot, but not when I have left an unsent email open; in that case main and editor window usually swap places. (When I say mildly annoyed, I meant mildly for someone with OCD/control tendencies ;))

One thing I wonder though: ultimately position and size are subject to the same issues. What happens when a window gets restored that was last opened on a screen with a (much) bigger size? From what I can see it's left to QWindow::size(), which may simply leave it to the WM to decide whether or not the window should be reduced in size. Given that the default position for the close, minimise and state buttons are on the right, they stand a good chance of falling off of a smaller screen, it seems.


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
Martin Gräßlin
2016-01-05 12:18:22 UTC
Permalink
Post by René J.V. Bertin
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.
I was afraid someone was going to say that, which is why I tried to argue that it's highly unexpected from a user viewpoint that only window size is saved and not position. How often would it happen that a developer is "highly surprised" in a *negative* way that window size AND position are restored on a platform where this is the default behaviour?
I have nothing against introducing a pair of new methods, but how is that supposed to be done in transparent fashion? I do have a lot against a need to change all dependent software to call those methods (maintenance burden and all that).
Counter proposal: replace save/restoreWindowSize with save/restoreWindowGeometry everywhere, with a platform-specific interpretation of what exactly geometry encompasses. Much less surprise there, just a bit more need to read the documentation. Are these functions ever called intentionally outside of what I suppose is a more or less automatic feature that takes care of restoring window, erm, layout (saving is clearly automatic).
Just to be clear: if I am going to introduce restore/saveWindowGeometry methods they'll replace the WindowSize variants on OS X or at least those will then use a different KConfig key to avoid conflicts.
I'd also be dropping the MS Windows part of the patch (as this is not a decision I want to make for a platform I don't use).
But please consider this: that KConfig key has been called `geometry` for a long time. Where exactly is the surprise, that restore/saveWindowSize never did what the key they operate with suggests, or that they have always been using an inaptly named key? For me the answer is straightforward and based on what users will expect...
I leave it to the maintainers. On API I maintain I would say no to something changing the semantics like that.
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.
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.
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.)
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.
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`)?
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.
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?
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).
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.
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.
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.
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.
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].
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.
One should be careful with this kind of reasoning: just because it is impossible to satisfy all demands and possible scenarii doesn't mean one can/should simply give up even for the simple cases - and certainly not on other platforms where the situation is completely different. The Mac OS has supported changeable resolutions and spanning desktops ever since screens were introduced that supported more than a single resolution and later computers that supported more than 1 monitor. I've been using multi-screen set-ups since my first Mac, a IIx which got its 2nd monitor in '90 or '91. Yes, changing a composite desktop layout is a nightmare when trying to do something sensible with windows. Mac OS (X) isn't perfect in that domain: it will for instance resize windows if they don't fit on the screen (but only if they're against the border). Very annoying, but you learn to live with it. In my opinion it's always better than windows that open somewhere else every time they open.
If things change and you can restore windows like they were, fine. If not, maybe you can place them in a position that is close enough so that the user still perceives it as the expected position (as a long-time Mac user I am inevitably influenced by Apple's ideas about spatial memory in UIs). It's not the end of the world if part of the window is off-screen because I'm reopening it on a screen with a different size. It may surprise at first, but I don't think you should underestimate the experience of users who get to work with multiple sets of (external) monitors. It seems highly unlikely they'll be the kind of user who just cannot understand why that window doesn't fit and restore exactly where they left it on some other screen.
@David: I've done exactly the same, for years, alternating between 3 different externals, where the only constant was the relative position of my laptop's screen w.r.t. (0,0) which was always on the external. On OS X you can switch to the login screen before you disconnect the external; that way the windows of your session stay put (and you can disconnect before suspending the host, and reconnect after waking it again, IOW the screen change isn't done "behind its back").
One should be careful with this kind of reasoning: just because it is impossible to satisfy all demands and possible scenarii doesn't mean one can/should simply give up even for the simple cases
on the other hand one should also not ignore the feedback by the domain experts :-) On X11 I don't want that as I think that it does more harm than it provides benefits. If you want it for OSX: go for it. But please not on X11.
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.
I'm not saying something like this has to be implemented for X11. I do think it'd be a valid approach to use WM hints for position and then leave it up to the WM what to do with the information (possibly depending on how the user configured that WM), but ultimately it is indeed up to domain experts to decide.
But: if KF5 wants to do things the Mac way, and that way is different from the X11 way, how can you not end up using a different solution?
As to half-baked features: do you think that applies to QWidget::save/restoreGeometry (regardless of whether we can use it here)? It's really a pity in that sense that KConfig has to be so lean in its dependencies.
Also, I have been noticing (and mildly annoyed about it) that certain of the windows on my KDE4 session are being restored to where I left them (my 2 vertically-maximised Konsole windows, and the ones from my Chrome session), but most others are not. Kontact tends to end up more or less in the right spot, but not when I have left an unsent email open; in that case main and editor window usually swap places. (When I say mildly annoyed, I meant mildly for someone with OCD/control tendencies ;))
One thing I wonder though: ultimately position and size are subject to the same issues. What happens when a window gets restored that was last opened on a screen with a (much) bigger size? From what I can see it's left to QWindow::size(), which may simply leave it to the WM to decide whether or not the window should be reduced in size. Given that the default position for the close, minimise and state buttons are on the right, they stand a good chance of falling off of a smaller screen, it seems.
so I'm not sure how the magic wayland will fix everything in that respect.
windows don't have a position they know on Wayland. If on Wayland we want to store the information, it would be KWin doing that and KWin knows on which screen it is, how the configuration looks like, etc. etc. But more important on mapping a window it would know whether the information is valid (KWin has a hash over the screen setup on Wayland). On X11 it just cannot know. It would have to trust the windows to not request stupid positions. Screens btw. is not the only thing to consider: panels/struts might have changed, placement policies might have changed, the window manager might have changed, etc. etc. Setting the position is something the WM has to do, not the application. On Wayland the application can not even try it.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89665
-----------------------------------------------------------
Post by René J.V. Bertin
-----------------------------------------------------------
https://git.reviewboard.kde.org/r/126324/
-----------------------------------------------------------
(Updated Dec. 14, 2015, 5:04 p.m.)
Review request for KDE Software on Mac OS X and KDE Frameworks.
Repository: kconfig
Description
-------
In KDElibs4, the KMainWindow::saveWindowSize() and KMainWindow::restoreWindowSize() function saved and restored not only the size but also the position (i.e. the geometry) of windows, using QWidget::saveGeometry and QWidget::restoreGeometry.
- 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.
```
--- 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)
#endif
```
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
Loading...