> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> >
>
> Jaime Torres Amate wrote:
> 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.
>
> René J.V. Bertin wrote:
> 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!)
>
> Jaime Torres Amate wrote:
> 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
-----------------------------------------------------------
On Dec. 14, 2015, 5:04 p.m., René J.V. Bertin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> -----------------------------------------------------------
>
> (Updated Dec. 14, 2015, 5:04 p.m.)
>
>
> Review request for KDE Software on Mac OS X and KDE Frameworks.
>
>
> Repository: kconfig
>
>
> Description
> -------
>
> In KDElibs4, the KMainWindow::saveWindowSize() and
> KMainWindow::restoreWindowSize() function saved and restored not only the
> size but also the position (i.e. the geometry) of windows, using
> QWidget::saveGeometry and QWidget::restoreGeometry.
>
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that
> functionality (and I suppose most modern WMs have the feature enabled by
> default?)
>
> Both arguments are moot on MS Windows and OS X, and on both platforms users
> expect to see window positions restored as well as window size. On OS X there
> is also little choice in the matter: most applications offer the geometry
> restore without asking (IIRC it is the same on MS Windows).
>
> I would thus like to propose to port the platform-specific code that existed
> for MS Windows (and for OS X as a MacPorts patch that apparently was never
> submitted upstreams). I realise that this violates the message conveyed by
> the function names but I would like to think that this is a case where
> function is more important.
>
> You may also notice that the Mac version does not store resolution-specific
> settings. This happens to work best on OS X, where multi-screen support has
> been present since the early nineties, and where window geometry is restored
> regardless of the screen resolution (i.e. connect a different external screen
> with a different resolution, and windows will reopen as they were on that
> screen, not with some default geometry).
> I required I can update the comments in the header to reflect this subtlety.
>
> Note that for optimal functionality a companion patch to `KMainWindow::event`
> is required:
> ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
> {
> K_D(KMainWindow);
> switch (ev->type()) {
> -#ifdef Q_OS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
> case QEvent::Move:
> #endif
> case QEvent::Resize:
> ```
>
> This ensures that the window geometry save is performed also after a move (to
> update the position) without requiring a dummy resizing operation.
> Do I need to create a separate RR for this change or is it small enough that
> I can push it if and when this RR is accepted?
>
>
> Diffs
> -----
>
> src/gui/kwindowconfig.h 48a8f3c
> src/gui/kwindowconfig.cpp d2f355c
>
> Diff: https://git.reviewboard.kde.org/r/126324/diff/
>
>
> Testing
> -------
>
> On OS X 10.6 through 10.9 with various KDElibs4 versions and now with Qt
> 5.5.1 and frameworks 5.16.0 (and Kate as a test application).
> I presume that the MS Windows code has been tested sufficiently in KDELibs4;
> I have only adapted it to Qt5 and tested if it builds.
>
>
> Thanks,
>
> René J.V. Bertin
>
>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
