Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/ --- (Updated Sept. 25, 2014, 4:02 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Qt KDE. Changes --- added qt-kde for potentially adding a call/switch to Q(Core)Application, which would do the CoreFoundation I'm an agent magic. 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/#review67423 --- kglobalaccel/main.cpp https://git.reviewboard.kde.org/r/120354/#comment47052 how long will the just be valid? Someone reading this code in lets say five years? I would either remove the comment or make it a more generic comment (no I, no time reference). kglobalaccel/main.cpp https://git.reviewboard.kde.org/r/120354/#comment47053 it's obvious that the include is needed, otherwise one wouldn't add it. I think that comment is not adding any information - Martin Gräßlin On Sept. 25, 2014, 4:02 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. 25, 2014, 4:02 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Qt KDE. 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/ --- (Updated Sept. 25, 2014, 4:58 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Qt KDE. Changes --- Address the issues Marin raised. 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 (updated) - 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/#review67428 --- kglobalaccel/main.cpp https://git.reviewboard.kde.org/r/120354/#comment47057 looks like an unrelated code line deletion. - Martin Gräßlin On Sept. 25, 2014, 4:58 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. 25, 2014, 4:58 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Qt KDE. 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/ --- (Updated Sept. 25, 2014, 5:22 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Qt KDE. 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 (updated) - 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/#review67431 --- kglobalaccel/main.cpp https://git.reviewboard.kde.org/r/120354/#comment47058 now there are two deleted lines... - Martin Gräßlin On Sept. 25, 2014, 5:22 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. 25, 2014, 5:22 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Qt KDE. 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/ --- (Updated Sept. 25, 2014, 6:14 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Qt KDE. 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 (updated) - 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
On Sept. 25, 2014, 5:58 p.m., Martin Gräßlin wrote: kglobalaccel/main.cpp, lines 48-55 https://git.reviewboard.kde.org/r/120354/diff/4/?file=315460#file315460line48 now there are two deleted lines... My bad, I could so hardly believe that one might want 2 empty lines there that your critique flipped sense in my mind ... - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/#review67431 --- On Sept. 25, 2014, 5:22 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. 25, 2014, 5:22 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Qt KDE. 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/#review67470 --- Ship it! Looks good to me, though I can of course not comment on the platform specific code. - Martin Gräßlin On Sept. 25, 2014, 6:14 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. 25, 2014, 6:14 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Qt KDE. 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/#review67376 --- 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. - Martin Gräßlin On Sept. 24, 2014, 5:45 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:45 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/ --- (Updated Sept. 24, 2014, 7:23 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime and kdelibs. Changes --- added code reformatted using KDevelop's KDELibs style 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 (updated) - 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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
On Sept. 24, 2014, 7: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. 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 ? - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/#review67376 --- On Sept. 24, 2014, 7: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, 7: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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
On Sept. 24, 2014, 7: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 ? 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. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/#review67376 --- On Sept. 24, 2014, 7: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, 7: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
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
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
