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
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