[KDE/Mac] Review Request 120354: [OS X] turn kglobalaccel into an "agent", removing it from Dock and application switcher

[Ian Wadham]

> On Sept. 24, 2014, 5:10 p.m., Martin Gräßlin wrote:
> > Please watch coding style and please also have a look at the frameworks variant. It still needs porting to MacOS *hint,hint* and that would be very, very appreciated. I recently sent a mail to frameworks-devel concerning moving the daemon into the framework. Would be great if you could have a look at it and help that we have MacOS support soon in the framework.
> 
> René J.V. Bertin wrote:
>     "It" being kglobalaccel? Or the change to set "agentship" from the running app, preferably by adding an API call somewhere so that end applications don't have to dabble in CoreFoundation code?
>     The former I can't help you with because as you know I cannot run anything KF5 in the foreseeable future. The latter is something I could work on, but again without testing.
>     
>     Oh, wait, you're asking me to port to MacOS. Hmmm, I doubt Qt ever existed even for version 9 of that venerable old pile of cultural luggage O:-)
>     (MacOS is what was used before Mac OS X came out. You're good at spotting whitespace differences, so I don't have to explain any further :P )
>     
>     As to kglobalaccel: I've taken this app as a demonstration case because it's one of a handful daemons that cluttered my Dock (the others being nepomukfilewatch and nepomukstorage, not sure patches to those are of any relevance?).
>     But I have no actual idea to what kglobalaccel does and to what extent it does that on OS X too. I haven't noticed any loss in (shortcut) functionality after quitting it... is there something I could try to see if it is required? 
>     
>     Also, the KDE4 version is the same on OS X and on Linux, why would the KF5 version require porting ?
> 
> Martin Gräßlin wrote:
>     > Also, the KDE4 version is the same on OS X and on Linux, why would the KF5 version require porting ?
>     
>     well the X11 version needed porting due to the switch to QPA. So I assume that other platforms need porting, too.

QPA? So we all have to have green hair now?... :-) See http://qt-project.org/videos/watch/qpa-the-qt-platform-abstraction or is there some other "QPA"?... :-)

@Martin: On a serious note, can you give us the exact link on kde-frameworks-devel archives that you are talking about? I think only Marko is a member of that list. Could your post have any connection with upcoming discussions I am about to start on kde-core-devel, re kdeinit4, klauncher, kded4, kwrapper and friends?

Our priority is to get KDE background processes working properly (or at all) in KDE 4 on Apple OS X, because KF5 is a distant mirage for the KDE-Mac group and the MacPorts users (except for Marko). However, if KDE-Mac work has spinoffs for the Frameworks/KF5 effort, well and good. We are already starting to see that happen. If we could get more dialog going with KDE core developers, all of us could proceed a lot faster and we could all benefit.


- Ian


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


On Sept. 24, 2014, 5:23 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120354/
> -----------------------------------------------------------
> 
> (Updated Sept. 24, 2014, 5:23 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Runtime and kdelibs.
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> -------
> 
> See https://bugs.kde.org/show_bug.cgi?id=339333 for more detailed discussion.
> 
> KDE helper applications that need to be able to present widgets or otherwise "talk with the GUI layer" require special attention on OS X, if one doesn't want them to appear in the Dock or task switcher nor present a bare-bones menubar when made active.
> 
> Applications that live in an app bundle can set LSUIElement="1" in their Info.plist to signal the window server that they're "agents" (and thus don't want the aforementioned visual presence). This feature is already in use (see Info.plis.template for apps like kded4 and kdeinit4, and the corresponding code in their respective CMake files).
> 
> kglobalaccel is a different case as it's built as a standard *n*x app (`/opt/local/bin/kglobalaccel` in a standard MacPorts install) and thus has no Info.plist. It is however possible to set the corresponding bit via CoreFoundation, and that's what this patch does.
> 
> Suggestion: a member function I'd tentatively call `appIsService` would be welcome, but one could also make this the default behaviour when starting a `GUIenabled=false` application on OS X.
> That's actually the main reason for submitting this RR: see if we can come to a consensus if and how to use this new knowledge.
> 
> 
> Diffs
> -----
> 
>   kglobalaccel/main.cpp 4d230b8 
> 
> Diff: https://git.reviewboard.kde.org/r/120354/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.6.8 with kdelibs 4.14.1 (git/kde4.14).
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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