Liu Jin wrote:
"Joel" == Joel de Guzman <joel@boost-consulting.com> 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