[PATCH weston 4/8] protocol: crop & scale RFC v3
spitzak at gmail.com
Mon Dec 2 12:23:37 PST 2013
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
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.
More information about the wayland-devel