> 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 ...
>
> René J.V. Bertin wrote:
> 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 <thi...@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.
OK, so I added `QApplication::setAttribute(AA_MacPluginApplication)` to
kglobalaccel, as close as possible to the beginning of KDEMain (= instead of
the CoreFoundation code that I pushed to HEAD earlier today). In this location,
setting that attribute (or `AA_DontUseNativeMenuBar`) did NOT have the intended
effect: kglobalaccel remained visible in the Dock, the AppSwitcher, and still
had a menubar with the application menu. I didn't really note whether that menu
had an items in it, but that's a moot point.
When I did the same tests with the Qt5 'systray' example application, I got a
very comparable result. With both attributes I still get the same presence in
Dock, app switcher and menubar. With `AA_MacPluginApplication` the system tray
*icon* disappears, but the menu can still be obtained by clicking in the empty
spot (which of course takes up space). With `AA_MacPluginApplication`, the
application menu is empty, but visible on the menu bar. That's probably
unavoidable (and means the app doesn't have its own menu) when an application
is visible in the dock and app switcher.
The only way for that example app to become a true plugin is to use the
aforementioned CoreFoundation code :
` CFBundleRef mainBundle = CFBundleGetMainBundle();
if (mainBundle) {
// get the application's Info Dictionary. For app bundles this
would live in the bundle's Info.plist,
// for regular executables it is obtained in another way.
CFMutableDictionaryRef infoDict = (CFMutableDictionaryRef)
CFBundleGetInfoDictionary(mainBundle);
if (infoDict) {
// Add or set the "LSUIElement" key with/to value "1". This
can simply be a CFString.
CFDictionarySetValue(infoDict, CFSTR("LSUIElement"),
CFSTR("1"));
// That's it. We're now considered as an "agent" by the
window server, and thus will have
// neither menubar nor presence in the Dock or App Switcher.
}
}
`
which would be suitable for an application that lives in the systemtray or
doesn't have a public interface at all unless it decides to open a dialog.
Note also that the `QCocoaIntegration` ctor UNSETS `AA_DontUseNativeMenuBar` as
one of its first actions ... and that `TransformProcessType` (see my previous
post) can only make a foreground application out of a background application on
OS X 10.6 and earlier.
- 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
>
>
