On Oct 18, 2012, at 10:07 AM, Sorvig Morten <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
