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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
