[KDE/Mac] Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled

Fri Sep 26 14:14:53 UTC 2014

> On Sept. 25, 2014, 8:07 p.m., Thomas Lübking wrote:
> > Aside Thiagos concern, what actually causes the menubar/docker item stuff?
> > 
> > Quoting QApplication (4.8):
> > > On X11, the window system is initialized if GUIenabled is true. If GUIenabled is false, the application does not connect to the X server. On Windows and Mac OS, currently the window system is always initialized, regardless of the value of GUIenabled. This may change in future versions of Qt.
> > 
> > So it's perhaps rather a statement in KApplicationPrivate::init() which causes this?
> > There aren't too many depending on GUIEnabled ... ;-)
> 
> René J.V. Bertin wrote:
>     Thiagos?
>     
>     The menubar/Dock "item stuff" is the result of `qt_mac_loadMenuNib` in `qapplication_mac.mm`, which is called when `!QApplication::testAttribute(Qt::AA_MacPluginApplication)`. Setting `GUIenabled=false` has that effect, ultimately.
> 
> Thomas Lübking wrote:
>     > Thiagos?
>     
>     By mail:
>     http://lists.kde.org/?l=kde-core-devel&m=141166670217317&w=2
>     
>     > result of qt_mac_loadMenuNib in qapplication_mac.mm
>     
>     Ok, so the API doc lied to me ;-)
>     Since the attributes are static, you could simply set it before creating the application in the relevant main funcs, could you?
>     (Though i actually don't see it set anywhere - but it's late and i'm tired...)
> 
> René J.V. Bertin wrote:
>     Ah, apparently Thiago missed the multiple recent reminders of the fact that we OS X users are going to be "stuck" in/with KDE4 for a tad longer than the average Linux user (Debian apart, maybe? ;))
>     Anyway, I guess I'm going to have to look again at how exactly `GUIenabled=false` leads to the qt_menu.nib not being loaded in Qt ...
>     
>     I don't think the API docs lied to you. Not loading the menu nib doesn't mean that the window system is not initialised ...

Taking this back to RR:

On Friday September 26 2014 13:33:20 Thomas Lübking wrote:
> On Freitag, 26. September 2014 10:41:39 CEST, Ben Cooksley wrote:
> > Applying a solution to a single OS is inherently wrong
> 
> > On Fri, Sep 26, 2014 at 5:01 PM, Thiago Macieira <thiago at kde.org> wrote:
> >> And still it needs to be studied for Qt5
> 
> Afaics there are two major issues with this patch (and actually they make everyone right in this thread ;-)
> 
> 1. It's Qt4 only
> 2. It's the broadsword
> 
> We can skip 1 (which is not "fixable", the API doesn't exist anymore) and should focus on 2 - and the foil may implicitly handle this as well ;-)

You know 4.8.7 is in the making? ;)
Also, concerning QApplication (4.8):
>On X11, the window system is initialized if GUIenabled is true. If GUIenabled is false, the application does not connect to the X server

That may be true for Qapplication, but KApplication does preciously little with GUIenabled. It's either ignored on X11, or only serves to determine whether the clipboard is initialised or not.

> It is too broadsword as, as mentioned by Thiago, the GUIEnabled parameter has several implications on all systems (let alone that the patch attempts to control it by the so far unrelated NOGUI cmake switch).

True, but what *does* the NOGUI switch do? Not much that I can see, until now. I'd still like to make a case that if there is such a switch, it'd best do what you'd expect it to do. It's unambiguous as can be, and removes the burden of having to remember the exact call and add it to code you're working on - actually, also the burden of knowing about the issue in the first place!
This is the same argument a Qt5 dev gave me for their heuristics menurole guessing feature.

> Luckily the behavior whether there's a menubar and stuff on OSX can be controlled by a QCoreApplication attribute that *is* OSX specific:
> 
>    Qt::AA_MacPluginApplication

[So I went on a little profiling spree :)]

Indeed, but this is not exactly what `GUIenabled=false` leads to ultimately in Qt4, on OS X. `qt_appType` is set to `QApplication::Tty` which is in fact the default (at least in Qt4) instead of `QApplication::GuiClient`, which in turn sets the global bool variable `qt_is_gui_used=false`.
`qt_is_gui_used` is read in the OS X `qt_init()` function (in qapplication_mac.mm), and controls a whole lot more than what `AA_MacPluginApplication` controls. Roughly speaking, one can resume that the window system isn't initialised *at all* when `qt_is_gui_used==false`.
Note that `qt_init` reads out the `LSUIElement` flag (as well as `LSBackgroundOnly`) from the app's InfoDictionary (Info.plist or set programmatically). This is then used to call `TransformProcessType(&psn, kProcessTransformToForegroundApplication)`, or not. (I'm surprised to see that it'd be up to the application to take that Info.plist flag into account; I'd have guessed the window manager would take care of it.)

 *FYI*: In Qt 5.3.1, `qt_appType` is called `qapplication_type`, `qt_is_gui_used` exists, but is no longer used in `qt_init` which I've found only in `qapplication_qpa.cpp` and not in any platform-specific code. `AA_MacPluginApplication` is read out in `QCocoaIntegration::QCocoaIntegration` (qcocoaintegration.mm). That same ctor handles the readout of `LSUIElement` through a call to `qt_mac_transformProccessToForegroundApplication()` (qcocoahelpers.mm), which is called only when `qEnvironmentVariableIsEmpty("QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM")` (which just checks `getenv`, nothing more fancy).
 Most of the window system calls made when `qt_is_gui_used==true` in Qt4.8 but independent of AA_MacPluginApplication have moved all over the place in Qt 5.3 .

> So my very first attempt would be to set that (unconditionally, ie. on all systems - it should be idempotent outside OSX anyway) before instantiating the application in the main funcs of the problematic applications AND LEAVE THE GUIEnabled PARAMETER UNTOUCHED.

Not sure it's not as simple as that. Reading back up on what `GUIenabled=false` makes me understand why an application like kglobabaccel crashes (aborts) when build with that setting. It tries to do things for which the window system must have been initialised.
I'll try to see what happens when I do `QApplication::setAttribute(AA_MacPluginApplication)` or `ditto AA_DontUseNativeMenuBar` (but without my CoreFoundation patch) in kglobalaccel.

But supposing that it indeed has the intended effect, surely you're not proposing to make it the default, obliging every applications that does want to present a full-blown GUI to unset the attribute?!

> Charmingly, such change would be Qt5 compatible =)

It remains to be seen whether the attribute has the same effect. Fortunately I do have a little Qt5-only test application with which I can test such things.

> Personally I doubt that this needs to or should be injected by a cmake parameter, but added directly (notably since this will only affect a fistful of applications in KDE anyway)

"this" being what, the NOGUI cmake parameter? There's quite a few of those around in kde-workspace, kde-baseapps and (esp.) the kdepim packages.

- René J.V.

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

On Sept. 25, 2014, 3:32 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120363/
> -----------------------------------------------------------
> 
> (Updated Sept. 25, 2014, 3:32 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> -------
> 
> Applications can be defined in their CMake file as being `NOGUI`, but until now this has had very limited effect. Especially on OS X, those applications can still construct a minimal GUI and thus have "visual presence" in the Dock and application switcher (and have a menubar as well).
> 
> This patch proposes to define a preprocessor token, `KDE_WITHOUT_GUI`, for those targets, and uses that token to set the default value for the `GUIenabled` option of the `KApplication` and `KUniqueApplication` classes.
> 
> This could potentially be combined on OS X with the CoreFoundation call that turns a running application into an "agent" (see https://git.reviewboard.kde.org/r/120354).
> 
> 
> Diffs
> -----
> 
>   cmake/modules/KDE4Macros.cmake 073d726 
>   kdeui/kernel/kapplication.h fa2ab26 
>   kdeui/kernel/kapplication.cpp b093034 
>   kdeui/kernel/kuniqueapplication.h e05dcd7 
> 
> Diff: https://git.reviewboard.kde.org/r/120363/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.6.8 with kdelibs 4.14.1 (git/kde4.14), rebuilt kdelibs, kde-workspace, kde-runtime, kde-baseapps, kdepim-runtime and nepomuk-core.
> If the documentation I read is correct, the `GUIenabled` switch has no effect on Linux, so this patch shouldn't have any either on that OS.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20140926/f69f9aef/attachment-0001.html>