using device targets in qml plasmoids

Sebastian Kügler sebas at kde.org
Wed Oct 24 14:09:23 UTC 2012


On Wednesday, October 24, 2012 15:35:39 Aaron J. Seigo wrote:
> On Wednesday, October 24, 2012 14:58:32 Sebastian Kügler wrote:
> > I've also found that I don't need touch-specific stuff in the app code
> > itself, the input specific things are already sorted in PlasmaComponents,
> > using those, I didn't need a single touch-specific widget. So input is
> > solved at the "toolkit" level, layout is solved at app level.
> 
> generally, yes. which is why i wasn't overly concerned. but the points you 
> raised are valid imho, and the proposed system does cover even the most "i 
> need to tweak everything" situation.
> 
> and yes, fallback to generic is a given  it always ends up in contents/ if 
> all else fails.

That sounds fine then. I feel that this conversation ends up saving a lot of 
headaches.

The fallback mechanism is something one needs to get a feeling for when doing 
the architectural work of the app. It works very well, but one needs to know 
what one's doing.

By the way, something notmart and I discussed a few days ago ... it would be 
handy if we had the input method ("touch", ...) accessible from the QML 
runtime. In many cases, one only wants to apply small tweaks to a component, 
and having to have a copy of the entire Component, just with a slight 
behavioral change can then quickly lead to synchronization nightmares.
I'm not quite sure *how* to expose it, however. Adding a global var (future 
proof? namespace contamination?), putting it in the plasmoid object 
(semantics?), or as separate component (too much overhead for a simple 
string), all sound unattractive somehow. Ideas?
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


More information about the Plasma-devel mailing list