Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

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

(Updated June 18, 2016, 4:06 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Software on Mac OS X and KDE Frameworks.


Changes
---

Submitted with commit 865efa3af8e76db0012acd5da2a24e71231dad84 by René J.V. 
Bertin to branch master.


Repository: kded


Description
---

There should be no reason to build `kded5` as an app bundle on OS X, and with 
recent feedback in mind I postulated that marking it "nongui" 
(`ecm_mark_nongui_application`) would be acceptable on other platforms too.

Additionally, `kded5` doesn't have any more reason to appear in the Dock or app 
switcher, on OS X, so I have added the code to make it an agent.


Diffs
-

  CMakeLists.txt 72a912c 
  src/CMakeLists.txt 5e95df8 
  src/kded.cpp 8e5f7a9 

Diff: https://git.reviewboard.kde.org/r/126170/diff/


Testing
---

On OS X 10.9.5 and Linux with Qt 5.6.1 and FWs 5.22.0 .


File Attachments


example launchctl plist for auto-starting kded5
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/06/18/ad67bc98-6e43-47c7-9a0a-dbe7b3b8e11f__org.macports.kded5.plist


Thanks,

René J.V. Bertin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

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

(Updated June 18, 2016, 10:52 a.m.)


Review request for KDE Software on Mac OS X and KDE Frameworks.


Changes
---

bump and updated for git/master. Added a launchd plist for auto-starting kded5 
at login.


Repository: kded


Description
---

There should be no reason to build `kded5` as an app bundle on OS X, and with 
recent feedback in mind I postulated that marking it "nongui" 
(`ecm_mark_nongui_application`) would be acceptable on other platforms too.

Additionally, `kded5` doesn't have any more reason to appear in the Dock or app 
switcher, on OS X, so I have added the code to make it an agent.


Diffs (updated)
-

  CMakeLists.txt 72a912c 
  src/CMakeLists.txt 5e95df8 
  src/kded.cpp 8e5f7a9 

Diff: https://git.reviewboard.kde.org/r/126170/diff/


Testing
---

On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .


File Attachments (updated)


example launchctl plist for auto-starting kded5
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/06/18/ad67bc98-6e43-47c7-9a0a-dbe7b3b8e11f__org.macports.kded5.plist


Thanks,

René J.V. Bertin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[David Faure]

> On Dec. 2, 2015, 7:51 a.m., David Faure wrote:
> > Please kind in mind that kded must be able to pop up dialogs, though.
> > (cookie dialog, SSL cert messagebox + dialog, etc. etc.).
> > 
> > If making it an "agent" doesn't prevent it from showing GUI elements now 
> > and then, then no problem.
> 
> René J.V. Bertin wrote:
> With the earlier approach of setting `LSUIElement` that is guaranteed to 
> be the case.
> 
> I just checked; launching Qt's Assistant with 
> `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that 
> the application remains in the background; it can be brought into the 
> foreground, and it retains its presence in the Dock and app switcher.
> 
> IOW, I'm not really sure I understand why kded5 doesn't retain that 
> presence with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's 
> possible that all the env. variable does is postpone the actions that lead to 
> that presence. If that's true than we'd have to come back to the more 
> appropriate previous revision of this patch.
> 
> OTOH: the only dialogs I have seen under KDE4 that are related to kded 
> (unknown cert) were posted when kded4 was *not* running. Ditto for cookie 
> related things. Under what circumstances is kded supposed to present a GUI?
> 
> David Faure wrote:
> Here is an easy way to test this: do the same change for kiod in kio 
> (it's like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.
> 
> Except that with Qt 5.6 from git here (from some time ago) it asserts in 
> DBus (looking into that now)... but hopefully you have Qt 5.5 ?
> 
> René J.V. Bertin wrote:
> OK, here's a reason NOT to use 
> QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM: it has to be unset, and I'm 
> not sure when this would have to/could be done such that the variable is 
> picked up for kded5 itself, but not by anything that is launched subsequently.
> 
> If kded5 is used to start kdeinit5 for instances, everything launched 
> through there will launch in the background.
> 
> So I'm going to go back to the original proposition, because an 
> LSUIElement app is exactly what kded ought to be.
> 
> David Faure wrote:
> I don't understand what you're saying. kded5 isn't starting any other 
> processes, is it?
> 
> René J.V. Bertin wrote:
> kdeinit5 is auto-started as part of what I think is normal behaviour. So 
> if kded5 is started first, that's what starts kdeinit5. Shouldn't it?
> 
> My reasoning here is that users might be interested in the possibility to 
> prepare the KDE runtime infrastructure with an inoffensive and non-invasive 
> daemon process that is part of the infrastructure itself. It is my experience 
> with KDE4/Mac that not doing so, but leaving the bootstrapping until you 
> start some larger and (much) more complex application (or suite; think 
> starting Akonadi) can lead to subtle but annoying stability issues.
> 
> NB: starting kded5 through kdeinit5 does *not* work on OS X. I've had a 
> quick look to understand why, but quickly gave up due to the complexity of 
> the code.

If a user wants to prepare the runtime infrastructure, he/she should run 
kdeinit5, not kded5.
kdeinit5 is the master of everything; kded is just a bunch of on-demand 
services.

Apps started standalone, who then make a dbus call to kded might indeed start 
kded first, which would in turn start kdeinit.
But yeah, unset any env vars in kdeinit that shouldn't be set for the apps it 
starts, that makes sense.


- David


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


On Dec. 25, 2015, 9:14 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Dec. 25, 2015, 9:14 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp c7fdfee 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[David Faure]

> On Dec. 2, 2015, 7:51 a.m., David Faure wrote:
> > Please kind in mind that kded must be able to pop up dialogs, though.
> > (cookie dialog, SSL cert messagebox + dialog, etc. etc.).
> > 
> > If making it an "agent" doesn't prevent it from showing GUI elements now 
> > and then, then no problem.
> 
> René J.V. Bertin wrote:
> With the earlier approach of setting `LSUIElement` that is guaranteed to 
> be the case.
> 
> I just checked; launching Qt's Assistant with 
> `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that 
> the application remains in the background; it can be brought into the 
> foreground, and it retains its presence in the Dock and app switcher.
> 
> IOW, I'm not really sure I understand why kded5 doesn't retain that 
> presence with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's 
> possible that all the env. variable does is postpone the actions that lead to 
> that presence. If that's true than we'd have to come back to the more 
> appropriate previous revision of this patch.
> 
> OTOH: the only dialogs I have seen under KDE4 that are related to kded 
> (unknown cert) were posted when kded4 was *not* running. Ditto for cookie 
> related things. Under what circumstances is kded supposed to present a GUI?
> 
> David Faure wrote:
> Here is an easy way to test this: do the same change for kiod in kio 
> (it's like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.
> 
> Except that with Qt 5.6 from git here (from some time ago) it asserts in 
> DBus (looking into that now)... but hopefully you have Qt 5.5 ?
> 
> René J.V. Bertin wrote:
> OK, here's a reason NOT to use 
> QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM: it has to be unset, and I'm 
> not sure when this would have to/could be done such that the variable is 
> picked up for kded5 itself, but not by anything that is launched subsequently.
> 
> If kded5 is used to start kdeinit5 for instances, everything launched 
> through there will launch in the background.
> 
> So I'm going to go back to the original proposition, because an 
> LSUIElement app is exactly what kded ought to be.
> 
> David Faure wrote:
> I don't understand what you're saying. kded5 isn't starting any other 
> processes, is it?
> 
> René J.V. Bertin wrote:
> kdeinit5 is auto-started as part of what I think is normal behaviour. So 
> if kded5 is started first, that's what starts kdeinit5. Shouldn't it?
> 
> My reasoning here is that users might be interested in the possibility to 
> prepare the KDE runtime infrastructure with an inoffensive and non-invasive 
> daemon process that is part of the infrastructure itself. It is my experience 
> with KDE4/Mac that not doing so, but leaving the bootstrapping until you 
> start some larger and (much) more complex application (or suite; think 
> starting Akonadi) can lead to subtle but annoying stability issues.
> 
> NB: starting kded5 through kdeinit5 does *not* work on OS X. I've had a 
> quick look to understand why, but quickly gave up due to the complexity of 
> the code.
> 
> David Faure wrote:
> If a user wants to prepare the runtime infrastructure, he/she should run 
> kdeinit5, not kded5.
> kdeinit5 is the master of everything; kded is just a bunch of on-demand 
> services.
> 
> Apps started standalone, who then make a dbus call to kded might indeed 
> start kded first, which would in turn start kdeinit.
> But yeah, unset any env vars in kdeinit that shouldn't be set for the 
> apps it starts, that makes sense.
> 
> René J.V. Bertin wrote:
> > If a user wants to prepare the runtime infrastructure, he/she should 
> run kdeinit5, not kded5.
> 
> The thing with that is that s/he would then have to launch 2 applications.
> 
> > Apps started standalone, who then make a dbus call to kded might indeed 
> start kded first
> 
> If that is also how `kdeinit5 --kded` starts kded, then that won't work. 
> The KDE daemon has always been tricky on OS X, and it just works best in 
> practice to let that application be the KDE bootstrap utility. We have to 
> take into consideration the fact that the session dbus itself is started 
> asynchronously through launchd, which makes relying on its presence (and 
> being operational) in order to launch other services tricky at best.
> 
> A "bunch of on-demand services" itself started on explicit user demand 
> and which activates the master of everything KDE when that's necessary 
> (without relying on the session dbus) ... what is wrong with the KDE Daemon 
> being the master puppet player like that, instead of startked on full Plasma 
> systems?

Users don't have to start kded by hand, it's dbus-activated when apps need it. 
Starting kdeinit is enough. In theory it's all autostarted, but I had to start 
kdeinit before ctest for 

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

> On Dec. 2, 2015, 8:51 a.m., David Faure wrote:
> > Please kind in mind that kded must be able to pop up dialogs, though.
> > (cookie dialog, SSL cert messagebox + dialog, etc. etc.).
> > 
> > If making it an "agent" doesn't prevent it from showing GUI elements now 
> > and then, then no problem.
> 
> René J.V. Bertin wrote:
> With the earlier approach of setting `LSUIElement` that is guaranteed to 
> be the case.
> 
> I just checked; launching Qt's Assistant with 
> `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that 
> the application remains in the background; it can be brought into the 
> foreground, and it retains its presence in the Dock and app switcher.
> 
> IOW, I'm not really sure I understand why kded5 doesn't retain that 
> presence with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's 
> possible that all the env. variable does is postpone the actions that lead to 
> that presence. If that's true than we'd have to come back to the more 
> appropriate previous revision of this patch.
> 
> OTOH: the only dialogs I have seen under KDE4 that are related to kded 
> (unknown cert) were posted when kded4 was *not* running. Ditto for cookie 
> related things. Under what circumstances is kded supposed to present a GUI?
> 
> David Faure wrote:
> Here is an easy way to test this: do the same change for kiod in kio 
> (it's like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.
> 
> Except that with Qt 5.6 from git here (from some time ago) it asserts in 
> DBus (looking into that now)... but hopefully you have Qt 5.5 ?
> 
> René J.V. Bertin wrote:
> OK, here's a reason NOT to use 
> QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM: it has to be unset, and I'm 
> not sure when this would have to/could be done such that the variable is 
> picked up for kded5 itself, but not by anything that is launched subsequently.
> 
> If kded5 is used to start kdeinit5 for instances, everything launched 
> through there will launch in the background.
> 
> So I'm going to go back to the original proposition, because an 
> LSUIElement app is exactly what kded ought to be.
> 
> David Faure wrote:
> I don't understand what you're saying. kded5 isn't starting any other 
> processes, is it?
> 
> René J.V. Bertin wrote:
> kdeinit5 is auto-started as part of what I think is normal behaviour. So 
> if kded5 is started first, that's what starts kdeinit5. Shouldn't it?
> 
> My reasoning here is that users might be interested in the possibility to 
> prepare the KDE runtime infrastructure with an inoffensive and non-invasive 
> daemon process that is part of the infrastructure itself. It is my experience 
> with KDE4/Mac that not doing so, but leaving the bootstrapping until you 
> start some larger and (much) more complex application (or suite; think 
> starting Akonadi) can lead to subtle but annoying stability issues.
> 
> NB: starting kded5 through kdeinit5 does *not* work on OS X. I've had a 
> quick look to understand why, but quickly gave up due to the complexity of 
> the code.
> 
> David Faure wrote:
> If a user wants to prepare the runtime infrastructure, he/she should run 
> kdeinit5, not kded5.
> kdeinit5 is the master of everything; kded is just a bunch of on-demand 
> services.
> 
> Apps started standalone, who then make a dbus call to kded might indeed 
> start kded first, which would in turn start kdeinit.
> But yeah, unset any env vars in kdeinit that shouldn't be set for the 
> apps it starts, that makes sense.

> If a user wants to prepare the runtime infrastructure, he/she should run 
> kdeinit5, not kded5.

The thing with that is that s/he would then have to launch 2 applications.

> Apps started standalone, who then make a dbus call to kded might indeed start 
> kded first

If that is also how `kdeinit5 --kded` starts kded, then that won't work. The 
KDE daemon has always been tricky on OS X, and it just works best in practice 
to let that application be the KDE bootstrap utility. We have to take into 
consideration the fact that the session dbus itself is started asynchronously 
through launchd, which makes relying on its presence (and being operational) in 
order to launch other services tricky at best.

A "bunch of on-demand services" itself started on explicit user demand and 
which activates the master of everything KDE when that's necessary (without 
relying on the session dbus) ... what is wrong with the KDE Daemon being the 
master puppet player like that, instead of startked on full Plasma systems?


- René J.V.


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


On Dec. 25, 2015, 10:14 p.m., René J.V. 

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

> On Dec. 2, 2015, 8:51 a.m., David Faure wrote:
> > Please kind in mind that kded must be able to pop up dialogs, though.
> > (cookie dialog, SSL cert messagebox + dialog, etc. etc.).
> > 
> > If making it an "agent" doesn't prevent it from showing GUI elements now 
> > and then, then no problem.
> 
> René J.V. Bertin wrote:
> With the earlier approach of setting `LSUIElement` that is guaranteed to 
> be the case.
> 
> I just checked; launching Qt's Assistant with 
> `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that 
> the application remains in the background; it can be brought into the 
> foreground, and it retains its presence in the Dock and app switcher.
> 
> IOW, I'm not really sure I understand why kded5 doesn't retain that 
> presence with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's 
> possible that all the env. variable does is postpone the actions that lead to 
> that presence. If that's true than we'd have to come back to the more 
> appropriate previous revision of this patch.
> 
> OTOH: the only dialogs I have seen under KDE4 that are related to kded 
> (unknown cert) were posted when kded4 was *not* running. Ditto for cookie 
> related things. Under what circumstances is kded supposed to present a GUI?
> 
> David Faure wrote:
> Here is an easy way to test this: do the same change for kiod in kio 
> (it's like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.
> 
> Except that with Qt 5.6 from git here (from some time ago) it asserts in 
> DBus (looking into that now)... but hopefully you have Qt 5.5 ?
> 
> René J.V. Bertin wrote:
> OK, here's a reason NOT to use 
> QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM: it has to be unset, and I'm 
> not sure when this would have to/could be done such that the variable is 
> picked up for kded5 itself, but not by anything that is launched subsequently.
> 
> If kded5 is used to start kdeinit5 for instances, everything launched 
> through there will launch in the background.
> 
> So I'm going to go back to the original proposition, because an 
> LSUIElement app is exactly what kded ought to be.
> 
> David Faure wrote:
> I don't understand what you're saying. kded5 isn't starting any other 
> processes, is it?
> 
> René J.V. Bertin wrote:
> kdeinit5 is auto-started as part of what I think is normal behaviour. So 
> if kded5 is started first, that's what starts kdeinit5. Shouldn't it?
> 
> My reasoning here is that users might be interested in the possibility to 
> prepare the KDE runtime infrastructure with an inoffensive and non-invasive 
> daemon process that is part of the infrastructure itself. It is my experience 
> with KDE4/Mac that not doing so, but leaving the bootstrapping until you 
> start some larger and (much) more complex application (or suite; think 
> starting Akonadi) can lead to subtle but annoying stability issues.
> 
> NB: starting kded5 through kdeinit5 does *not* work on OS X. I've had a 
> quick look to understand why, but quickly gave up due to the complexity of 
> the code.
> 
> David Faure wrote:
> If a user wants to prepare the runtime infrastructure, he/she should run 
> kdeinit5, not kded5.
> kdeinit5 is the master of everything; kded is just a bunch of on-demand 
> services.
> 
> Apps started standalone, who then make a dbus call to kded might indeed 
> start kded first, which would in turn start kdeinit.
> But yeah, unset any env vars in kdeinit that shouldn't be set for the 
> apps it starts, that makes sense.
> 
> René J.V. Bertin wrote:
> > If a user wants to prepare the runtime infrastructure, he/she should 
> run kdeinit5, not kded5.
> 
> The thing with that is that s/he would then have to launch 2 applications.
> 
> > Apps started standalone, who then make a dbus call to kded might indeed 
> start kded first
> 
> If that is also how `kdeinit5 --kded` starts kded, then that won't work. 
> The KDE daemon has always been tricky on OS X, and it just works best in 
> practice to let that application be the KDE bootstrap utility. We have to 
> take into consideration the fact that the session dbus itself is started 
> asynchronously through launchd, which makes relying on its presence (and 
> being operational) in order to launch other services tricky at best.
> 
> A "bunch of on-demand services" itself started on explicit user demand 
> and which activates the master of everything KDE when that's necessary 
> (without relying on the session dbus) ... what is wrong with the KDE Daemon 
> being the master puppet player like that, instead of startked on full Plasma 
> systems?
> 
> David Faure wrote:
> Users don't have to start kded by hand, it's dbus-activated when apps 
> need it. Starting kdeinit is enough. In theory it's all autostarted, but I 
> had to 

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

> On Dec. 2, 2015, 8:51 a.m., David Faure wrote:
> > Please kind in mind that kded must be able to pop up dialogs, though.
> > (cookie dialog, SSL cert messagebox + dialog, etc. etc.).
> > 
> > If making it an "agent" doesn't prevent it from showing GUI elements now 
> > and then, then no problem.
> 
> René J.V. Bertin wrote:
> With the earlier approach of setting `LSUIElement` that is guaranteed to 
> be the case.
> 
> I just checked; launching Qt's Assistant with 
> `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that 
> the application remains in the background; it can be brought into the 
> foreground, and it retains its presence in the Dock and app switcher.
> 
> IOW, I'm not really sure I understand why kded5 doesn't retain that 
> presence with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's 
> possible that all the env. variable does is postpone the actions that lead to 
> that presence. If that's true than we'd have to come back to the more 
> appropriate previous revision of this patch.
> 
> OTOH: the only dialogs I have seen under KDE4 that are related to kded 
> (unknown cert) were posted when kded4 was *not* running. Ditto for cookie 
> related things. Under what circumstances is kded supposed to present a GUI?
> 
> David Faure wrote:
> Here is an easy way to test this: do the same change for kiod in kio 
> (it's like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.
> 
> Except that with Qt 5.6 from git here (from some time ago) it asserts in 
> DBus (looking into that now)... but hopefully you have Qt 5.5 ?

OK, here's a reason NOT to use QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM: 
it has to be unset, and I'm not sure when this would have to/could be done such 
that the variable is picked up for kded5 itself, but not by anything that is 
launched subsequently.

If kded5 is used to start kdeinit5 for instances, everything launched through 
there will launch in the background.

So I'm going to go back to the original proposition, because an LSUIElement app 
is exactly what kded ought to be.


- René J.V.


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


On Nov. 25, 2015, 7:12 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 7:12 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

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

(Updated Dec. 25, 2015, 10:14 p.m.)


Review request for KDE Software on Mac OS X and KDE Frameworks.


Changes
---

This takes the patch back to my original proposition, because of my previous 
comment (avoid unheriting `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM`).

There is one additional minor modification: `KDE_FULL_SESSION` has no special 
meaning on OS X. Advanced users might set it however, to unblock certain 
functionality elsewhere. Shunting kde_running to false means `kdeinit5` can be 
started through `kded5` regardless of whether `KDE_FULL_SESSION` is set; 
`kded5` is a "logical" utility to start in order to bootstrap the KDE runtime 
infrastructure (e.g. via a launchd plist).


Repository: kded


Description
---

There should be no reason to build `kded5` as an app bundle on OS X, and with 
recent feedback in mind I postulated that marking it "nongui" 
(`ecm_mark_nongui_application`) would be acceptable on other platforms too.

Additionally, `kded5` doesn't have any more reason to appear in the Dock or app 
switcher, on OS X, so I have added the code to make it an agent.


Diffs (updated)
-

  src/CMakeLists.txt 5e95df8 
  src/kded.cpp c7fdfee 

Diff: https://git.reviewboard.kde.org/r/126170/diff/


Testing
---

On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .


Thanks,

René J.V. Bertin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[David Faure]

On Monday 07 December 2015 16:14:54 René J.V. Bertin wrote:
> On Sunday December 06 2015 14:51:40 David Faure wrote:
> 
> > Here is an easy way to test this: do the same change for kiod in kio (it's 
> > like a mini kded) and then
> > cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> > should bring up a password dialog.
> 
> Regardless of what I try (even with the non-agent'ised, non-nongui version), 
> I only get this:
> 
> CD kio/build/tests listjobtest.app/Contents/MacOS/listjobtest 
> "ftp://t...@upload.kde.org;
> Starting listJob for the URL: QUrl("ftp://t...@upload.kde.org;)
> Runtime: 291 milliseconds.
> Press Enter to quit.
> 
> kiod5 is started, but doesn't post a dialog. Doesn't raise/return an error 
> either.
> If there a debug category to activate in order to get more output I haven't 
> found it.

Did you try this on linux with Qt 5.4 or 5.5, to make sure there isn't another 
bug?

I'm still fighting Qt 5.6 with this, dbus-in-a-thread creates lots of 
additional trouble.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

On Sunday December 06 2015 14:51:40 David Faure wrote:

> Here is an easy way to test this: do the same change for kiod in kio (it's 
> like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.

Regardless of what I try (even with the non-agent'ised, non-nongui version), I 
only get this:

CD kio/build/tests listjobtest.app/Contents/MacOS/listjobtest 
"ftp://t...@upload.kde.org;
Starting listJob for the URL: QUrl("ftp://t...@upload.kde.org;)
Runtime: 291 milliseconds.
Press Enter to quit.

kiod5 is started, but doesn't post a dialog. Doesn't raise/return an error 
either.
If there a debug category to activate in order to get more output I haven't 
found it.

R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[David Faure]

> On Dec. 2, 2015, 7:51 a.m., David Faure wrote:
> > Please kind in mind that kded must be able to pop up dialogs, though.
> > (cookie dialog, SSL cert messagebox + dialog, etc. etc.).
> > 
> > If making it an "agent" doesn't prevent it from showing GUI elements now 
> > and then, then no problem.
> 
> René J.V. Bertin wrote:
> With the earlier approach of setting `LSUIElement` that is guaranteed to 
> be the case.
> 
> I just checked; launching Qt's Assistant with 
> `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that 
> the application remains in the background; it can be brought into the 
> foreground, and it retains its presence in the Dock and app switcher.
> 
> IOW, I'm not really sure I understand why kded5 doesn't retain that 
> presence with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's 
> possible that all the env. variable does is postpone the actions that lead to 
> that presence. If that's true than we'd have to come back to the more 
> appropriate previous revision of this patch.
> 
> OTOH: the only dialogs I have seen under KDE4 that are related to kded 
> (unknown cert) were posted when kded4 was *not* running. Ditto for cookie 
> related things. Under what circumstances is kded supposed to present a GUI?

Here is an easy way to test this: do the same change for kiod in kio (it's like 
a mini kded) and then
cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
should bring up a password dialog.

Except that with Qt 5.6 from git here (from some time ago) it asserts in DBus 
(looking into that now)... but hopefully you have Qt 5.5 ?


- David


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


On Nov. 25, 2015, 6:12 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 6:12 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

On Sunday December 06 2015 14:51:40 David Faure wrote:

> Here is an easy way to test this: do the same change for kiod in kio (it's 
> like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.

OK, hope to get around to doing that tomorrow.

> 
> Except that with Qt 5.6 from git here (from some time ago) it asserts in DBus 
> (looking into that now)... but hopefully you have Qt 5.5 ?

Yes.
Is that assert platform-specific? There has been a recent change that 
apparently removed DBus access from the OS X platform plugin, I hope that's not 
related? (I can dig out the code review ticket if you missed it.)

R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[David Faure]

On Sunday 06 December 2015 21:55:44 René J.V. Bertin wrote:
> On Sunday December 06 2015 14:51:40 David Faure wrote:
> 
> > Here is an easy way to test this: do the same change for kiod in kio (it's 
> > like a mini kded) and then
> > cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> > should bring up a password dialog.
> 
> OK, hope to get around to doing that tomorrow.
> 
> > 
> > Except that with Qt 5.6 from git here (from some time ago) it asserts in 
> > DBus (looking into that now)... but hopefully you have Qt 5.5 ?
> 
> Yes.
> Is that assert platform-specific? There has been a recent change that 
> apparently removed DBus access from the OS X platform plugin, I hope that's 
> not related? (I can dig out the code review ticket if you missed it.)

No, it's about dbus running in a secondary thread in Qt 5.6.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

> On Dec. 2, 2015, 8:51 a.m., David Faure wrote:
> > Please kind in mind that kded must be able to pop up dialogs, though.
> > (cookie dialog, SSL cert messagebox + dialog, etc. etc.).
> > 
> > If making it an "agent" doesn't prevent it from showing GUI elements now 
> > and then, then no problem.

With the earlier approach of setting `LSUIElement` that is guaranteed to be the 
case.

I just checked; launching Qt's Assistant with 
`QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that 
the application remains in the background; it can be brought into the 
foreground, and it retains its presence in the Dock and app switcher.

IOW, I'm not really sure I understand why kded5 doesn't retain that presence 
with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's possible that 
all the env. variable does is postpone the actions that lead to that presence. 
If that's true than we'd have to come back to the more appropriate previous 
revision of this patch.

OTOH: the only dialogs I have seen under KDE4 that are related to kded (unknown 
cert) were posted when kded4 was *not* running. Ditto for cookie related 
things. Under what circumstances is kded supposed to present a GUI?


- René J.V.


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


On Nov. 25, 2015, 7:12 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 7:12 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[David Faure]

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


Please kind in mind that kded must be able to pop up dialogs, though.
(cookie dialog, SSL cert messagebox + dialog, etc. etc.).

If making it an "agent" doesn't prevent it from showing GUI elements now and 
then, then no problem.

- David Faure


On Nov. 25, 2015, 6:12 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 6:12 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

On Nov. 25, 2015, 6:18 p.m., René J.V. Bertin wrote:
> > See qtbase/src/plugins/platforms/cocoa/qcocoaintegration.mm and 
> > qcocoahelpers.mm
> 
> René J.V. Bertin wrote:
> Isn't copy/paste a great tool? :)
> 
> Anyway, `qt_mac_transformProccessToForegroundApplication` only reads the 
> `LSUIElement` key to determine whether an application is allowed to be 
> transformed to a foreground application, and I don't see any evidence that it 
> is published. It appears to be intended to be called by default, unless the 
> env. variable `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` is set. Which 
> is a bit surprising, but doing a `putenv` of that variable at the start of 
> `kdemain` indeed does appear to have the desired effect.

ping?


- René J.V.


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


On Nov. 25, 2015, 7:12 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 7:12 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

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


Would it be an idea to create a framework function to run the CoreFoundation 
code to turn an application into an agent (set `LSUIElement` programmatically 
in the application dictionary), for instance in KCoreAddons?

- René J.V. Bertin


On Nov. 25, 2015, 6:08 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 6:08 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[Aleix Pol Gonzalez]

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



src/kded.cpp (line 683)


It seems like the function qt_mac_transformProccessToForegroundApplication 
is doing something along the lines in Qt's OS X QPA.

Maybe you could investigate a bit more into getting Qt to do the right 
thing?


See qtbase/src/plugins/platforms/cocoa/qcocoaintegration.mm and qcocoahelpers.mm

- Aleix Pol Gonzalez


On Nov. 25, 2015, 6:08 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 6:08 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

On Nov. 25, 2015, 6:18 p.m., René J.V. Bertin wrote:
> > See qtbase/src/plugins/platforms/cocoa/qcocoaintegration.mm and 
> > qcocoahelpers.mm

Isn't copy/paste a great tool? :)

Anyway, `qt_mac_transformProccessToForegroundApplication` only reads the 
`LSUIElement` key to determine whether an application is allowed to be 
transformed to a foreground application, and I don't see any evidence that it 
is published. It appears to be intended to be called by default, unless the 
env. variable `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` is set. Which 
is a bit surprising, but doing a `putenv` of that variable at the start of 
`kdemain` indeed does appear to have the desired effect.


- René J.V.


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


On Nov. 25, 2015, 6:08 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 6:08 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

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

(Updated Nov. 25, 2015, 7:12 p.m.)


Review request for KDE Software on Mac OS X and KDE Frameworks.


Changes
---

Achieve the same (hopefully!) effect by setting 
`QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM`.

`kded` is supposed to be a true daemon that doesn't even have a "systray" 
presence, so this mechanism may be suitable or even more appropriate. Time will 
have to tell.

What bothers me is that feature isn't documented, and also that it works 
differently from setting `LSUIElement`. If I read 
`qt_mac_transformProccessToForegroundApplication()` correctly, it is indeed the 
equivalent of setting `LSBackgrounOnly`, and that is *probably* inappropriate 
for applications that do need to become foreground for instance to post a 
dialog.


Repository: kded


Description
---

There should be no reason to build `kded5` as an app bundle on OS X, and with 
recent feedback in mind I postulated that marking it "nongui" 
(`ecm_mark_nongui_application`) would be acceptable on other platforms too.

Additionally, `kded5` doesn't have any more reason to appear in the Dock or app 
switcher, on OS X, so I have added the code to make it an agent.


Diffs (updated)
-

  CMakeLists.txt 4b9a5ff 
  src/CMakeLists.txt 5e95df8 
  src/kded.cpp 6929d7d 

Diff: https://git.reviewboard.kde.org/r/126170/diff/


Testing
---

On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .


Thanks,

René J.V. Bertin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel