[Development] extending QtMacExtras?

René J.V. Bertin rjvbertin at gmail.com
Mon Jan 18 11:02:35 CET 2016


Hi,

Mostly to have an idea about likelihoods and timescales:

How easy (or not) is it to get extensions for QtMacExtras accepted, and how likely that such extensions actually become available in an upcoming release?

One thing that's really missing from Qt at the moment is a way for an application that is not the foreground application to post a window in the foreground  (cf. also my thread on extending QProcess). To my knowledge this can only be done by forcing the application to the foreground using the same technique also used by the QCocoaIntegration ctor. Crude, but sometimes required.

A variant could take a WId and activate the application owning the corresponding window or widget. I'm not sure to what extent that would be trivial or even possible to implement (Jake? Morten?). It would allow to simulate things that can currently be done (only?) on Unix/X11:

1) hand off a request from a foreground application ("A") to a background process or daemon ("D"), providing it a target WId
2) from "D", post a dialog using that WId from "A" as the parent widget, ensuring that the dialog actually appears in "A"'s window layer
3) process the data from the dialog in "D", and return the result to "A" which never ceased being the foreground application.

Doing this on OS X would require bringing "D" to the foreground because  "D" cannot get any useful information from a WId owned by another application. Not making "D" foreground would mean the dialog will most likely remain hidden behind any number of other windows. In order to achieve 3), "D" would then have to use the WId to make "A" the foreground application again.

Are there other platforms where WIds cannot be used in a cross-application context? If so this functionality could very well suit the QDesktopServices class, but I guess that wouldn't speed up the deployment timescale ...

Regards,
René



More information about the Development mailing list