On Tue, Mar 26, 2013 at 6:07 AM, Marco Martin <notm...@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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
