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

From: Joel de Guzman (joel_at_[hidden])
Date: 2005-10-05 19:07:24

Liu Jin wrote:
>>>>>>"Joel" == Joel de Guzman <joel_at_[hidden]> writes:
> 
>     > Why not ;-) ? Replace "screen" with "paper" and you'll want to
>     > have accurate 1:1 layouts. This is the very essence of device
>     > independence. If, say, I want to print a PCB (printed circuit
>     > board) on a 300DPI laser printer, I'd want absolute accuracy,
>     > otherwise, my components will not fit the holes. Device
>     > independence means that both "screen" and "paper" should behave
>     > identically. If I want 10cm on paper how can I create such a
>     > thing in an abstracted relative coordinate system?
> 
> But you aren't going to draw a PCB on screen with boost.GUI widgets.
> Neither is it very likely that someone needs to print a copy of some
> on-screen dialog, in WYSIWYG manner.
> 
> So yes, the underlying (vector) graphic library should handle a whole
> collection of units and transformations. But widgets and the layout
> engine generally don't care about units. In the rare cases that they
> do, (e.g. you want a ruler widget exactly 10cm long) you can always
> use the graphic library to transform among units.

Have you read the Fresco doc that Stefan gave a link to? The point
is that life would be sooo much better if there is no distinction
between a "widget" and a "graphic". Think abstraction and genericity!
Here's the relevant quote:

'''
Conventional windowing environments provide separate
classes of objects for user interface components, or “widgets,”
and graphical objects. Widgets negotiate layout and can be
resized as rectangles, while graphics may be shared (not just
strictly hierarchical) transformed, transparent, and overlaid.
This presents a major obstacle to applications like user interface
builders and compound document editors where the
manipulated objects need to behave both like graphics and
widgets.

Fresco[1] blends graphics and widgets into a single class of
objects. We have an implementation of Fresco and an editor
called Fdraw that allows graphical objects to be composed like
widgets and widgets to be transformed and shared like graphics.
Performance measurements of Fdraw show that sharing
reduces memory usage without slowing down redisplay.
'''

Back in the mid 90s, I wrote a GUI framework inspired by Fresco.
As a proof of concept, I used the layouting capabilities to
render HTML (images, text flows, tables, lists, buttons, etc).
An html page is a hierarchical composition of active objects.
The result was awesome! Because of genericity, sharing and reuse,
the rendering engine's application footprint was constant. I
never had to write any special classes and instead relied solely
on object composition to compose a complex graphical entity.
The only thing I had to write was the HTML parser with semantic
actions that composed the page (ahh yes.. and that's how spirit
came to be...)

Now imagine... what if the same facility can be reused to create
your toolbars, menus, dialogs, etc. Imagine for instance---
creaing a dialog using an XML script. Creating a whole application,
for that matter, from XML. Then... attaching the "semantic actions"
to your business code.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net