DRAFT !!! copyright 2005 Michael David Emmel Every few years programmers seem to get together to implement yet another language, os or gui toolkit that will change the world. And every time they may add a little innovation but generally they fall into the same problems as there predecssors. The root cause of this problem seems to be that anyone that has tried these mega projects once does not do it agian and goes on to do something useful with there life.
Some how I've managed to get myself into the position of implementing multiple gui toolkits with little chance to escape to greener pastures. I'd like to share some of my experiences Before you begin: Get a modern graphics system or prepare to support one. You MUST have the following no exceptions or your wasting your time. 1.) Alpha blending of top level windows 2.) Full 2D api capable of supporting PDF,SVG,Java2D etc. 3.) Support for the ability too integrate 3D widgets 4.) Shaped/3D widgets including top level windows. 5.) True Type Font engine including support for getting outlines. 6.) Easy control of input including grabbing the events directly Currently OSX is the only platform that has mature support for these requirmentsbut you can use immature systems if they are evolving to meet your long term needs. The first mistake: Button Almost all gui toolkit developers initally start by developing the button widget. Which is a mistake since it sets a pattern followed throughout. To escape the trap you need to consider what the core of a gui is. If you think about it what drives a ui ? For me the answer to this question is 1.) Font Metrics 2.) Internationalization 3.) String layout 4.) Input methods. 5.) Focus and Focus Traversal Almost invariably these issues are dealt with in and adhoc manner or left till the last minute by gui toolkit implementers. First why are Font Metrics so important ? If you think about it the gui toolkit drawing is driven by the font. You can control the size of images by scaling if needed and also borders etc. What you can't control is the chosen font. Layout is driven at its deepest levels by the Strings that are to be displayed and there fonts. The primary goal of a ui should be to do the best job it can to fully display the strings present in a screen. To accomplish this goal you should spend a long time thinking about building a core string support system that manages the font metrics fonts and layout of the strings for your toolkit. First you should learn LaTeX and TeX document formatting seems to have become a lost art with wsiswyg (MS Word) and HTML slowly its being reinvented with CSS and a number of other "new technologies". I'm not saying that a String management system need the complexity of TeX but if you feel that you have a tenth of its power then your on the right track. This string manager should of course support your text editing widgets but more important it acts as the core layout manager for the whole system. It should support the following. Insets or Padding: There should be a system wide concept of padding around each string for display. Justification Left Right Center etc: You should be able to easily get requirments for text justified in various ways. Glue: Glue in a gui is a bit different from TeX generally what glue is the space between strings chars in a string and for a gui components. It related to padding butmore complex and variable. For gui's if you have a number of components on the screen you often want the text to lay on a grid. Many gui's have various kinds of grid based layout managers but if you consider the text as core with the components simply some padding around the text then the grid/glue layouts can be driven inside the text engine. I don't think there is a right answer for how you should implement the grid/glue system its a matter of complexity vs usability. Generally you should consider something that can handle variable size boxes and has a loose notion of grid positions. Don't overlook the fact that you may want to split a component into multiple grid positions and locking of widths heights and x y coordinates to constants for the layout algorithm. Jumping ahead if you have built this system your platform supports fillRectangle draw rectangle and draw string. You can finally play with laying out ui's that look like a bunch of strings and boxes. Now you can add two new aspects editing a string and images. Editing support from the ui perspective is pretty simple the String contains virtual chars that make it larger than its current contents and it is or can be fixed to this width. If you implemented before reading this part then you probably built everything around the actual chars in a string and you need to go back and allow the concept of "real" chars and virtual chars. Basically you need a max visual concept and the concept of locked for the maximum. This brings in the concept of preferred size which is generally driven off the size of the strings up through the widget layer. Since the system is based on string layout preferred size falls out naturally. This is a really really good time start to develop at least primitive input methods and deal with the various modes OnTheSpot OffTheSpot Root .. ancient egyptian :) Seriously the input method windows and drawing should disturb the ui as little as possible and handling them early is the best chance you have to be correct. Hopefully I don't need to mention that you better support utf8/unicode text. And you did remember to handle input methods and focus issues right ? Next images the other big component can be treated by the system if you wish as a custom ImageFont based on the string font generally you want to scale a image to match the dimensions or be related to the Font assigned to the component. Generally you want to not scale but instead the goal is to present the "best" image sizes for a given font. Agian looking at how LaTeX handles images is a good idea. Borders. Finally you can add cool borders generally they will be drawn at fixed pad distances and since they take up pixels on the screen they need to be included in the layout engine. Hopefully at this point there not too hard to handle. Now you can add your widget state machines event handling focus rects etc. Thats it you now have a world class modern widget toolkit believe it or not the rest is easy and left as and exercise to the reader. _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
