> On Dec. 17, 2015, 4: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!)

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
-----------------------------------------------------------


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

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to