[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-active
Subject: Re: components components components
From: Marco Martin <notmart () gmail ! com>
Date: 2011-11-07 18:10:01
Message-ID: 201111071910.02136.notmart () gmail ! com
[Download RAW message or body]
On Thursday 03 November 2011, Marco Martin wrote:
>
> Hi all,
> so.
> now the components are more or less finished.
>
as a title of experiment i have:
* alternative files in kde-
runtime/plasma/declarativeimports/plasmacomponents/platformcomponents/touch
* cmake installs everything both in:
$prefix/lib/kde4/imports/ and
$prefix/lib/kde4/platformimports/touch
now, what should happen is applications are supposed to read from ~/.plasmarc
Plasma-components-platform group to discover what series of components they
have to use. error prone, but it can be done in libkdeclarative.
then, they can do
QStringList importPaths = KGlobal::dirs()->findDirs("lib", "kde4/imports");
importPaths << KGlobal::dirs()->findDirs("lib", "kde4/platformimports/touch");
foreach (const QString &iPath, importPaths) {
engine()->addImportPath(iPath);
}
(this can be done in libkdeclarative as well)
and then the touch specific will "win" against the ones in imports
i also tought about just having an object that can tell at runtime if we have
a mouse or touch (so enable/disable mouseover effects) that would cover some
cases, but not all.
we will probably want to have both in the end (if we want to support hotplug
of a mouse in a nifty way) but i think something will still be quite different
enough bot aestetically or functionally (for instance i do *not* want to have
the Window component for instance in the plasma desktop components)
ok for everybody if i go forward that path and merge? comments?
Cheers,
Marco Martin
_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic