Pekka Paalanen wrote:
You have read it right.
Okay. I really have doubts this is correct but I guess I will go along with it and see.
Can I suggest that it be an *error* if buffer_scale is any value other than 1 on a surface that the scaling extension is being used. Under the current design it is useless and this would allow the meaning to be defined in a future extension to Wayland.
toolkits should be prepared to change the buffer_scale at will (window completely moves from HiDPI monitor to a low DPI one), so storing the scenegraph in buffer coordinates would be a lot of work for each change.
I don't think users that only have a high-dpi display are going to be really impressed with this feature.
In other words, all GUI elements are defined in integer surface coordinates.
Our GUI is defined in multiples of the general font size, and this value can be scaled by steps of approximately 15% by the ctrl+/= shortcuts. All other dimensions are either linear functions of this size or they are done by measuring the extents of text rendered with this font. Our "scenegraph" has no coordinates, instead widgets are laid out more like word-wrapped text, by finding their size and packing them into rows and columns. We never use direct x/y positions or sizes of widgets. Qt supports this type of layout and we are using their standard container widgets. Even the most primitive toolkits do some layout this way, for instance menu items are rarely given x+y positions, but instead figured out from the height of all the items before them. Most toolkits support a word-wrapped menubar or tab bar.
Trying other software (Nuke, Maya, Blender, Photoshop, many others) and resizing the windows clearly shows that our approach is pretty common.
Multiplying the font size by the output_scale is trivial and is how I would scale our gui. There are no other numbers to change. All you have done is thrown in a monkey wrench in that the code needs to be fixed to not assume that all integers are possible everywhere.
Defining GUI elements in smaller units is not useful, because people will not be able to take advantage of smaller things anyway: they cannot see it clearly, or they cannot poke it (input) accurately enough.
This is not true. The steps are easily visible when trying to drag a slider handle. Users can easily see irregularly-sized items because a dimension that is not a multiple of N was divided into N items that are supposed to be equal sized. Also the steps are very annoying for smooth scaling of the gui at small sizes because they cause abrupt changes in the layout, rather than a smooth flow that you get when changing the scale when it is very large.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
