On Thursday April 20 2017 12:20:17 Tor Arne Vestbø wrote: > I see the problem you are trying to solve, but I don't think it's worth > it to maintain a separate code path for this legacy mode that conflicts > with the platform behavior.
That's the question, is this platform behaviour one should impose on the user, or is support for an alternative mode/behaviour an added value for certain users or uses? I know I'm not the only one who's annoyed by the loss of content on all my other screens when I put an app in fullscreen mode, and also that Apple are very unlikely to admit they're wrong in their approach with its inconsistent behaviour. If fullscreen mode is supposed to help you concentrate on a single task, why would it allow the use of other screens in one MissionControl configuration (say for related tasks requiring other apps or even other windows of the same app) and not in the other? This is not documented anywhere that I know of, so I think the blackening is more a side-effect of using a temporary Space to create fullscreen mode than a design principle that you're not allowed to work around. BTW, the same can be said for the screensHaveSeparateSpaces mode: why would it be impossible there to watch a fullscreen video without being bothered by light pollution from your other screens if that's what you want? In fact, I think they persist because we still have a choice: 1) use screensHaveSeparateSpaces (Joe User solution) 2) provide a "legacy" mode (a term I'm beginning to doubt, btw) in software where that's justified (e.g. when the user prefers it). If 1) were easier (immediate effect) we wouldn't need 2) but as long as that's not the case I'll defend 2) or resort to 3) avoid fullscreen mode and prefer applications that provide the kind of fullscreen mode I want. I hadn't noticed before I started tweaking the 5.9.0 Cocoa QPA, but the 5.8.0 Cocoa QPA has almost the same fallback-to-legacy fullscreen as I just implemented. (My implementation is a bit more feature-complete by now, IMHO :)) BTW, I noticed another reason why I prefer this kind of implementation: it's instantaneous and lacks the useless animation. R. > > tor arne > > On 20/04/2017 00:04, René J. V. Bertin wrote: > > Hi, > > > > I went ahead and tinkered with Qt4's code: > > > > https://github.com/RJVB/shortcut-test-qt5/blob/master/mainwindow.cpp#L302 > > > > QCocoaWindow inherits only QObject, not QWidget or QWindow, so implementing > > this > > logic in the Cocoa QPA was a bit more work but not impossible: > > > > https://cgit.kde.org/scratch/rjvbb/osx-integration.git/tree/src/qcocoa-qpa/qcocoawindow.mm?h=qt590#n1906 > > > > This PoC implementation applies the "legacy" (old-style) fullscreen mode to > > windows without the fullscreen titlebar button, and when > > QT_LEGACY_FULLSCREEN is > > set. In the latter case it appears to be a good idea to unset > > Qt::WindowFullscreenButtonHint because otherwise certain events restore the > > window frame (decoration). > > > > R > > _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
