----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126520/#review94339 -----------------------------------------------------------
src/klauncher/klauncher.h (line 279) <https://git.reviewboard.kde.org/r/126520/#comment64152> You shoudln't/can't have Q* classes outside of Qt. Also does this really need to be in klauncher.h? It's not even being exported. - Aleix Pol Gonzalez On April 6, 2016, 7:18 p.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126520/ > ----------------------------------------------------------- > > (Updated April 6, 2016, 7:18 p.m.) > > > Review request for KDE Software on Mac OS X and KDE Frameworks. > > > Repository: kinit > > > Description > ------- > > OS X has an annoying habit that almost seems deliberate to turn users away > from applications doing things the Posix way. Launching an executable via > `system()` or one of the `exec()` functions causes it to open in the layer > behind the calling process. That means the launched application can remain > undetected, all the more if it wasn't started because of an explicit user > action. Example: the kwalletmanager5 kcm would open behind the kwalletmanager > itself, leaving the user to wonder why the menu action didn't work. > > I spent a lot of time working on a workaround, getting the system to force > the newly started application to the front without having access to the > AppKit SDK that would allow to do that from the application itself. > Finally I realised, almost by accident, that I was looking at a side effect > of turning `kded5` into an "agent" (GUI application without presence in Dock, > AppSwitcher and menubar) via `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM > `. That env. variable is evidently inherited by `kdeinit5` when started > through kded5, and from there by all processes launched by kdeinit. > > I have of course resolved the issue at the root, but am submitting the > workaround I came up with as a showcase snippet (i.e. not as something I > think useful to incorporate "as is"). It shows how to get AppleScript to do > something it isn't really designed to do: use the "System Events" library to > check for a running process, and then tell it to activate (come to the > foreground). The AppleScript is still a bit rough, and only has a single end > condition (telling the app to activate). I'm using a subclassed `QProcess` > class to run this script with a timeout. > > > Diffs > ----- > > src/klauncher/klauncher.h 53c0803 > src/klauncher/klauncher.cpp baa5649 > > Diff: https://git.reviewboard.kde.org/r/126520/diff/ > > > Testing > ------- > > On OS X 10.9.5 with KF5rameworks 5.17.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
