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