On Wednesday, October 24, 2012 12:16:37 Sebastian Kügler wrote:
> On Wednesday, October 24, 2012 11:41:17 Aaron J. Seigo wrote:
> > thoughts?
>
> Not quite happy with it, with my experience from the microblog app. There,
> the orthogonal input / layout makes complete sense, as you get the
> following combinations:
>
> touch / widget:   perfect for smartphone screen, using limited space and
>                                                               touch-friendly 
> input
> touch / tablet:       suitable for tablets ("biggish" screen, touch input)
> normal / tablet:      fine for desktops, works well with mouse, uses 
> screenspace
> avaiable
> normal / widget:  Usable as desktop widget
>
> I think screensize/layout and input method should stay separate things.

agreed; the way this would be done in the plasmoid package is components that
are for touch (input interaction) go into touch/ and components specific to a
screen format such as tablet would go into tablet/ (form factor)

so on a tablet the search path becomes tablet -> touch -> contents

on a handset it might become widget -> touch -> contents

on a desktop it might become widget -> desktop -> contents

this would be achieved by setting PLASMA_PLATFORM to "tablet:touch",
"widget:touch" and "widget:desktop" respectively

so the hierarchy would essentially be: Form Factor Specific -> Input Method
Specific -> Universal assets

this means we need to define what the valid combinations and names are and
settle on them so that people can reliably write UIs :)

--
Aaron J. Seigo

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to