[Development] Theming in the future
I think i can expect that any application that builds for the target architecture will work...
But does hardware adaptation include tweaks to, e.g. the Silica.Theme constants?
When new hardware arrives, which should be soon, applications will have to adapt to different screen resolution.
How is theming going to change to allow different screen sizes and DPI?
For example, for a 4.5" screen with a higher DPI I would probably want the theme to report larger pixel sizes for fonts and maybe icons.
On a tablet, with larger screen but higher resolution, we would probably want most measurement to stay the same, but maybe have larger Theme.fontSizeLarge.
On a small screen device, with a low DPI, sizes should be tweaked as well, but what would be the best compromise I cannot tell without trying, you need to have buttons and widgets big enough that activating them by touch is reliable.
It would be useful to know what is the expected behavior, and best practices we can put in place to be sure our applications will still work on a variety of display -- and maybe, having a tool to test various configurations.
The SDK could have different simulators with e.g a 480x800 screen, and a 1280x800 screen, to let us try the interface on a small device and a tablet, for example.
I am not sure I chose the right title. Should it be "Improve theming and UI guidelines?" maybe? Any other suggestion?
mikelima ( 2014-03-07 10:56:50 +0200 )edit"For example, for a 4.5" screen with a higher DPI ... the theme to report larger pixel sizes"
You probably mean "smaller" pixel sizes.
I do not know, how it is working with Sailfish, but in general it is a good idea to have a parameter "true pixel size" in µm, or even better, "user experience pixel size" e.g. in minimum number of pixel per text line height (i.e. the user can adjust this parameter using a general scale to increase/decrease the size of UI elements according to the own sight and actual screen/pixel size; at least not yet user accessible implemented in Sailfish). Apps should use this parameter to decide on the default/minimum size of UI elements.
jgr ( 2014-03-07 13:01:23 +0200 )edit@jgr - I meant larger, but that is because I am thinking of the way the font is specified... Because fonts size is specified in pixels in the Theme API, if you have a higher DPI screen, if you want the size of the font to be the same, you want larger values reported bt Theme.fontSizeMedium and friends.
At least part of the problem would be solved if font size were specified in points, but that is not enough to have a good layout: Larger devices (tablets) are probably kept at larger distances than phones, so you may want larger fonts yet.
In the end, whoever does a port to a new device will probably have to tweak the Theme class as well... I hope this can be changed without rebuilding the library, however. :)
mikelima ( 2014-03-07 13:28:37 +0200 )edit@mikelima: Ok, not "larger pixel sizes" but "larger pixel numbers".
If there would be a user scaling for fonts, you would not have to care for screen sizes, screen dpi and reading distances: The user would specify to have all, for example 120% larger than the ex-factory OS UI implementation specifies and your app would be fed with the pixel numbers as the user wants it to suit her/him best. So you just have to use the pixel numbers provided by the OS to be correct (for the user).
(It seems, that this user scaling is not yet implemented, at least not yet user accessible.)
jgr ( 2014-03-07 13:39:56 +0200 )edit@jgr - The font size should work as long as you use the Theme interface... but there are other sizes that may need further clarification, for example icon sizes:
On small low-dpi devices you may want smaller icons (not physically smaller, but smaller in pixel count). On larger devices, you want the icon to be at least big enough that you can hit them easily, but you do not want necessarily to scale them alongside the text. So, at least, we may need multiple icon sizes, versus the single 86x86 icons we ship. Same for IconButtons and similar...
mikelima ( 2014-03-07 13:53:55 +0200 )edit