Re: [boost] GUI coordinate units (Was: GUI foundations)

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-10-05 08:00:55

Vladimir Prus wrote:
> Stefan Seefeld wrote:
> 
> 
>>>>I'm not sure I understand what you mean by 'unit' here. Imagine you want
>>>>to print a portion of the screen. Do you expect dimensions to be
>>>>preserved on paper or not ? I do.
>>>
>>>
>>>Physical dimenstions? In millimeters? Then I don't expect this. Say the
>>>program shows a chart in a window. It's natural to print that chart to
>>>occupy full size of A4 paper (if A4 is the current paper size), or have
>>>page layout customizable.
>>
>>I don't quite understand what you are saying. There are certainly
>>graphical objects without an intrinsic (physical) size that can scale to
>>whatever region is available.
> 
> 
> Then I don't understand what you said before. You said you expect that
> printing of portion of screen should preserve dimenstions. Do you mean
> dimensions in millmeters or in what unit? And why do you expect for them to
> be preserved on paper?

Yes, I'm talking about physical dimensions (millimeters, whatever). Why
should I *not* expect it to preserve its size ?

>>>>What you describe is true for 'non-terminals' in the tree only. All leaf
>>>>nodes (glyphs, icons, but also some part of the widgets themselves, such
>>>>as bevels, slider and scrollbar handles, etc., etc.) do need their own
>>>>size.
>>>
>>>
>>>Right, but those sizes should be configurable by user and never tweaked
>>>by developer. The logic in the library to determine slider width, for
>>>example, might be complicated, but it should be inside library. Do you
>>>ever needed to explicitly set scrollbar width?
>>
>>These sizes are typically determined by the GUI designer. 
> 
> 
> Who is, or what is "GUI designer". A human designing program, and human
> writing library, or a tool for designing GUIs? In which OS, or GUI library, 
> the width of scrollbar is easily configurable?

The person designing a new GUI ('toolkit') is the one who sets 'style'
attributes such as this one. I'v never said that it is (or should be)
easily configurable.

>>They may or may 
>>not be configurable by users. My point is that don't want 'screen
>>resolution' to interfer with them either. Users may scale ('zoom') the
>>whole GUI to adjust it to their eyes.
> 
> 
> Maybe we look from different angles. I think that application writers should
> not care about this.

I fully agree.

> The GUI library sets the size of main windows, and the
> size may in any unit it likes. The application will then adjust all child
> windows in due *proportion* to the main window size and draw content. The
> display on monitor is done by GUI library, so it scales content as it
> likes.

Let me rephrase that a bit: the application asks the display server
for a region of suitable size, such that all it wants to draw will fit in.
This size requirement will be a fuction of the size of the graphical elements
they lay inside (and, I reiterate, which generally should have physical dimensions).

So, it's not that the content will be scaled 'in due proportion' to fit into
the main window, but the main window will get a size suitable for the content.

Thus, scaling isn't done implicitely to fit content to a main window (or screen).
While there may be graphics that don't have an intrinsic size, and thus are
easily scalable, most will not.

>>Device coordinates are not ok to determine object size, because that means
>>that objects have differing sizes on different output devices (multiple
>>screens, printers, etc.) and so users wrongly tweak resolution to get back
>>their wanted object sizes.
> 
> 
> You should never specify object size at all. The size of main window should
> be set the GUI library, or set as proportion of screen size.

The size of a composite graphic should be determined by negotiating the required
size (range) necessary to draw the content with the size the screen (or generally,
parent graphic) provides.
See http://fresco.org/docs/papers/blending.pdf for a description of this process.

I believe that scaling a text viewer such as in a pdf viewer when you resize
the main window is the exception, not the rule. It is much more common to reflow
the text, or to restrict the possible size of the main window.

Regards,
                Stefan