> 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.
I don't understand what you're saying. kded5 isn't starting any other processes, is it? - 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel