* Marcelo E. Magallon <mmagallo@debian.org> [2004-12-28 16:42]:
On Thu, Dec 23, 2004 at 12:11:08PM -0500, Alan Gutierrez wrote:
I'd like to look at how OS X is able to make a PDF of everything. Observing that capability lead me to believe that you could simply swap out the underlying device.
That's easy: you start with a vector description of *everything* and plug a rasterizer where needed. This vector description in Quartz is called DPS: Display PostScript.
This gives you the gimmicks you see on MacOS X, for example window minimization and maximization effects. You just need to start with a rectangle, and subdivide the edges, and apply some transformation to them. Then you can use algebraic grid generation to compute the inner grid. And now you only need to apply the grid transformation to the elements of the window.
Thinking: ui -> paint ui -> box ui -> component One can create components by using resource handles, one can draw boxes using a very simple device, or work with vector graphics. Different abstractions of drawing. On weak devices components or boxes are the best you will get. On better devices you can paint. On Palm you might do box<render_as<native>>, simple aaboxes. On OS X you do box<render_as<native>>, native vector described aaboxes. On Win32 you do box<render_as<paint>>, for a software implementation of vector described aaboxes. Same with components. component<render_as<resource>> component<render_as<box>> component<render_as<paint>> button<render_as<native>> on OS X is Aqua. button<render_as<native>> on Win32 requires an HWND. button<render_as<paint>> on Win32 is "light-weight". Where canvas is a vector graphics library: canvas<render_as<box>> causes a compile time error. Current thinking: ui -> window ui -> box ui -> paint ui -> component ui -> form ui -> grid ui -> document ui -> canvas . . . (binding, validation, accesibility, mvp, etc.) What I'm driving at. A wide, but shallow, scope. -- Alan Gutierrez - alan@engrm.com