Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Martin Gräßlin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Martin Gräßlin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Martin Gräßlin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[David Faure]

> On Dec. 17, 2015, 4:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Martin Gräßlin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[David Faure]

> On Dec. 17, 2015, 4:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[David Faure]

> On Dec. 17, 2015, 4:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Martin Gräßlin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[David Faure]

> On Dec. 17, 2015, 4:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

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

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


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 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Jaime Torres Amate]

> On Dec. 17, 2015, 4:16 p.m., Martin Gräßlin 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.


- 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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Jaime Torres Amate]

> 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 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[David Faure]

> On Dec. 17, 2015, 4:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.

Note that most apps use this via the higher-level 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.

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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Martin Gräßlin]

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


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


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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > 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
---


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 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).

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


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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Martin Gräßlin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...

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


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 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 14, 2015, 7:53 a.m., Martin Gräßlin wrote:
> > src/gui/CMakeLists.txt, line 2
> > 
> >
> > 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.
> 
> René J.V. Bertin wrote:
> 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".
> 
> Boudhayan Gupta wrote:
> 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
---


On Dec. 13, 2015, 2:54 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. 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.
> 
> 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. 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Boudhayan Gupta]

> On Dec. 14, 2015, 12:23 p.m., Martin Gräßlin wrote:
> > src/gui/CMakeLists.txt, line 2
> > 
> >
> > 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.
> 
> René J.V. Bertin wrote:
> 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".

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


On Dec. 13, 2015, 7:24 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. 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.
> 
> 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
> 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Boudhayan Gupta]

> On Dec. 14, 2015, 12:23 p.m., Martin Gräßlin wrote:
> > src/gui/CMakeLists.txt, line 2
> > 
> >
> > 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.
> 
> René J.V. Bertin wrote:
> 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".
> 
> Boudhayan Gupta wrote:
> 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.
> 
> René J.V. Bertin wrote:
> 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
---


On Dec. 13, 2015, 7:24 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. 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.
> 
> 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 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

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

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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 14, 2015, 12:47 p.m., Marco Martin wrote:
> > src/gui/CMakeLists.txt, line 22
> > 
> >
> > we really can't add a dependency to QWidgets here.
> > depending on qwidgets will make many potential interested project not 
> > able to use it
> 
> Alex Richardson wrote:
> 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
---


On Dec. 13, 2015, 2:54 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. 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.
> 
> 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/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
> 
>

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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Boudhayan Gupta]

> On Dec. 14, 2015, 5:17 p.m., Marco Martin wrote:
> > src/gui/CMakeLists.txt, line 22
> > 
> >
> > we really can't add a dependency to QWidgets here.
> > depending on qwidgets will make many potential interested project not 
> > able to use it
> 
> Alex Richardson wrote:
> 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
> 
> René J.V. Bertin wrote:
> 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?)
> 
> Boudhayan Gupta wrote:
> 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
---


On Dec. 13, 2015, 7:24 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. 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.
> 
> 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/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,
> 
> 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Boudhayan Gupta]

> On Dec. 14, 2015, 5:17 p.m., Marco Martin wrote:
> > src/gui/CMakeLists.txt, line 22
> > 
> >
> > we really can't add a dependency to QWidgets here.
> > depending on qwidgets will make many potential interested project not 
> > able to use it
> 
> Alex Richardson wrote:
> 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
> 
> René J.V. Bertin wrote:
> 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
---


On Dec. 13, 2015, 7:24 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. 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.
> 
> 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/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
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 14, 2015, 7:53 a.m., Martin Gräßlin wrote:
> > src/gui/CMakeLists.txt, line 2
> > 
> >
> > 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
---


On Dec. 13, 2015, 2:54 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. 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.
> 
> 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 

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

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

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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126324/#review89447
---



src/gui/CMakeLists.txt (line 2)


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


On Dec. 13, 2015, 2:54 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. 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.
> 
> 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/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
> 
>

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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

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

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