In the "Getting rid of build keys" thread, I wrote: > In light of that and the Mac App Store guidelines, I'd propose that on Mac > and Windows Qt never have global configuration. The configuration belongs > to the applications.
I'd like to propose we go one step further: Qt proper has *no* global
configuration settings, at all. Anything and everything you can set in qtconfig
should be gone from Qt as Qt settings, including the widget style. And there
may be other settings that you can configure in ~/.config/Trolltech.conf or
equivalent, but aren't in qtconfig (such as the order of the OK and Cancel
buttons). I'd also like to include most of the settings provided by the System
Information module of Qt Mobility.
Those settings should instead be provided by the platform plugin.
In the absence of the platform plugin, Qt should use reasonable defaults,
including values that it may detect from the underlying system (especially Mac
and Windows).
Some settings may be overridden by the application, such as UI language. But
there's absolutely no point in overriding the cursor blinking rate or the
click/drag radius threshold.
I recommend the following order (later entries override earlier ones):
1) Qt-provided reasonable defaults
2) Qt-detected system settings, like Unix LANG; Mac and Windows windowing
system settings (i.e., the Lighthouse plugin)
3) the actual platform plugin
4) overrides by the application
This should allow applications running on platforms where Qt is not a system
library (Mac, Windows, some Unix systems) to run with reasonable defaults and
integrate with the platform.
On platforms where Qt is a system library, Qt cannot integrate upwards without
the plugin's help (cyclic dependency problem). So this plugin will provide the
required information. That way, Qt applications running inside KDE will get
KDE's setting of date/time, for example. Qt will not have to make exceptions
for other Qt-based platforms, like Harmattan.
A GNOME platform plugin is also suggested, reading settings from wherever
GNOME stores them.
The interface I propose for this is one front-end class in Qt, ostensibly
named QSystemConfiguration, with one or more static functions of the signature:
static QVariant configuration(ConfigurationEntry entry);
where ConfigurationEntry is an enum. This is inspired à la sysconf(3) and
pathconf(3) on Unix.
This configuration setting should be exposed to QML too.
Classes like Mobility's System Information can be provided as wrappers, in
order to give C++ type safety. Unlike System Information, those methods should
be static -- the physical dimensions of my display do not change if I
instantiate another object.
Both the Lighthouse plugin and the platform plugin shall have a virtual
function like this. The function should return an invalid QVariant when it
doesn't know the value for this configuration, in which case the Qt code will
try to obtain the fallback value.
The System Information backend plugins should then be folded into the platform
plugin and the Lighthouse plugin, as appropriate.
The only problem with this is that this is an "I propose", not an "I will do".
Are there any volunteers for this work?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
