Review Request 126520: [OS X] try to [k]launch the requested application in the foreground [showcase]

[René J.V. Bertin]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160407/b6e076dc/attachment-0001.html>