FYI: Platform content discussion in Qt

[Alan Alpert]

On Tue, Mar 26, 2013 at 6:07 AM, Marco Martin <notmart at gmail.com> wrote:
> On Tuesday 26 March 2013, Alan Alpert wrote:
>> Hi,
>>
>> I can't find it now, but there was a note on one of the Plasma wiki
>> pages about some of the limitations of how QML files are 'switched
>> out' with platform content versions in a Plasma package (from memory,
>> stuff like requiring a qmldir and not working with C++ plugins).
>
> iirc only part on the wiki that talked about packages was:
> http://techbase.kde.org/Development/Tutorials/Plasma/PackageOverview#Device_specific_user_interface

Maybe it wasn't written down :P . There is the issue that by
redirecting to files using a custom QNAM set on the QQmlEngine means
that remote file limitations are applied, which means requiring a
qmldir and not loading C++ plugins.

> i think the limitation was on another thing, that wasn't about packages:
> we have also components (as in the hopefully standard qtcomponents set) in
> multiple versions for desktop and touch.
> we have just some components that are actually rewritten for touch usage,
> while most are just fine, but we have to install the whole set two times,
> because what we would want is:
>
> import org.kde.plasma.components 1.0 as...
>
> and import the "right" set, but the ideal way is (if we are importing touch
> components) to have a set of "just" the components that are rewritten for
> touchscreen, while falling back to the common ones for everything else, that
> now we can't do, so we have the whole set installed two times and we change
> the import paths depending from the platform, and that's not optimal.

If the selectors were implemented at a Qt or QML level, then you could
easily apply them in your imports the same as you would in plasma
packages. So that problem would be solved too.

--
Alan Alpert