https://bugs.kde.org/show_bug.cgi?id=379009
Bug ID: 379009
Summary: Mac: working around an undesirable multihead/Mission
Control/fullscreen side-effect?
Product: frameworks-kconfigwidgets
Version: unspecified
Platform: Compiled Sources
OS: OS X
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: general
Assignee: kdelibs-b...@kde.org
Reporter: rjvber...@gmail.com
Target Milestone: ---
Flags: Brainstorm+
Sorry, long text. This is an issue that requires some background information...
Long-time Mac users with external/multiple screens may be aware of an IMHO
undesirable side-effect that occurs when you chose the more common (?)
configuration for virtual desktops ("Spaces") where each desktop (Space) spans
all available screens, and switching happens simultaneously on all screens.
Apple implement their native fullscreen mode using a temporary "Space" on which
the window is then maximised. It will occupy all of the screen on which it
already lived, but the temporary Space spans all screens, effectively blacking
them out.
This does not happen in the default Mission Control mode where screens have
separate Spaces (and each screen a menubar). In that configuration the native
fullscreen behaviour works exactly as you'd expect (with a time-consuming,
useless animation thrown in for good measure): making a window fullscreen on
any given screen doesn't affect the content being displayed on other screens.
This wouldn't be much of an issue if the screensHaveSeparateSpaces property
could be toggled with immediate effect, but in practice you have to log off and
back in again. Not very practical if you want to watch a fullscreen video while
keeping an eye on your email client displayed on a secondary screen, or if you
want to maximise an IDE for a complex edit in a huge file but still be able to
look up documentation say in a web browser running on another screen.
There is no difficulty implementing a standard fullscreen algorithm that simply
puts the target window in frameless mode and sizes it to cover a complete
screen. This can be done with a few Qt calls, and doesn't require any
undocumented native SDK calls or hacks.
In fact, Qt 5.8.0 and earlier implemented such an algorithm as a fallback for
windows lacking the fullscreen titlebar button
(`Qt::WindowFullscreenButtonHint` unset). It seems that Qt's PoV has changed
with v5.9.0 that such an alternative fullscreen is "non-platform behaviour" and
thus to be proscribed; if "we" want it "we" just have to roll our own
algorithm. That wouldn't be a big deal in a context of a few individual
applications, but it's a bit different in the context of KF5 frameworks that
aim to extend Qt with additions which improve user and/or developer experience
one way or another - including an "enter/exit fullscreen" KStandardAction.
Would there be an open-minded attitude towards propositions to introduce an
optional "simple, basic" fullscreen mode that makes windows fullscreen by
resizing and removing decoration?
The way I see it:
- this is not "non-platform behaviour" as the main and intended effect is the
same (window is displayed occupying all of its current screen) and it requires
no hacking
- this provides a consistent fullscreen experience on multi-head set-ups,
across Mission Control configurations but also across platforms
- screens not occupied by a fullscreen window remain usable as usual
- yay, no waiting for a pointless animation (1s nominal, more if the system is
stressed)
- this avoids running into what's probably an OS X bug (creating a new window
in a fullscreen'ed application replaces the window that was made fullscreen and
causes the latter to go MIA without closing it properly.
I have a working PoC implementation in a personal fork of Qt's 5.9.0RC Cocoa
platform plugin (which overrides the standard QPA) but I'd prefer to keep the
changes in that fork as low as possible.
--
You are receiving this mail because:
You are watching all bug changes.
