Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-10-05 07:05:08

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?

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

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

The model only breaks with bitmap images, but well, that's not fixable.

>>>I think we are in violent agreement. Mouse events are reported in the
>>>coordinate system of the target region (window, widget, surface, whatever
>>>you name it). All I'm saying is that this coordinate system should
>>>reflect physical size, i.e. be independent from device-space coordinates.
>>>Unfortunately, traditionally GUIs are tied to a particular device and
>>>thus it is custom to express coordinates in the device's own coordinate
>> But this does not cause any problems I know about. If you know about any
>> problems, please tell! Say mouse events coordinates are mostly usefull
>> for testing which object mouse is over, or for positioning popup menu, or
>> something like that. In those cases, using device coordinates are OK.
> 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 child
windows should be laid out by GUI or resizes as proportion of main windows
size. So, you don't care what unit is used, since you never specify
absolute sizes.

So, I believe that the ideal coordinate system unit is nothing more that

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at