[Development] Porting exported qt_[win|mac|x11] functions Qt 5.

[Knoll Lars]

On Oct 18, 2012, at 10:07 AM, Sorvig Morten <Morten.Sorvig at digia.com> wrote:

> According to git grep Qt 4 has 47 semi-public exported "qt_platform" functions offering platform-spesific functionality. Most platform code is now in plugins and can no longer export symbols. We need a plan for dealing with these in Qt 5.
> 
> After a brief investigation these fall into several categories (some are in more than one category):
> 
> - helper functions for other parts of Qt (qt_win_display_dc?)
> - utility functions (qt_mac_execute_apple_script, qt_mac_secure_keyboard)
> - access to Qt platform internals (qt_mac_nativeview_for)
> - obsolete (qt_mac_from_pascal_string)
> - strange (qt_mac_resolve_sys which just calls dlsym)
> 
> Proposed solution 0) Ignore the problem for Qt 5.0.
> 
> Proposed solution 1) Fix it:
> 
> - Remove/don't port obsolete functions (we can add them back later if it was a mistake)
> - Add to QPA where it makes sense. The QPlatformNativeInterface subclasses already gives access to may platform internal objects.
> - Public compatibility API goes int the platform extras modules. Many of the utility functions can be implemented here as well.
> - Create "extras" modules for all platforms (we currently have qtmacextras in the Qt playground)
> - Add the extras modules to the default Qt 5 distribution.
> 
> Given the current workload and schedule solution 0) is actually tempting, at least for me. Releasing 5.0 with missing functions will perhaps tell us which ones are in use.

I'd say we go with solution (0) for 5.0. But we'll need to pick this up again after the 5.0 release, create the platform specific add-ons and add them to the default distribution.
> 
> Does anyone want to pick this up?

Even if we do, I doubt the things will be ready in time for 5.0. Let's add them afterwards.

Cheers,
Lars