> On April 6, 2016, 7:26 p.m., Aleix Pol Gonzalez wrote: > > src/klauncher/klauncher.h, line 279 > > <https://git.reviewboard.kde.org/r/126520/diff/2/?file=455690#file455690line279> > > > > 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.
Really - watch me! :) Seriously, what would be a better name - KTimeoutProcess? I suppose I put it in the header in order to be sure that moc would process the class, but I guess that's not required (if it ever was). I've also been considering to move this into kinit_mac.mm (= kdeinit5 for OS X) but I am not really sure where that would have to go. FWIW, at about the time I created this RR, David and I started discussing the idea of a class (or QProcess modification) for doing "GUI/Desktop launches" on platforms where there's a difference between those and POSIX style fork+exec. I'll have to refresh my memory, but IIRC we didn't really come to a concensus, and there was definitely no warm welcome for the idea from upstream Qt. I haven't written off the idea, though, and am still open to working on this, either as something specific to kdeinit5 or why not as an extension to KProcess. - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126520/#review94339 ----------------------------------------------------------- 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
