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