Hi Petr, sorry for the first incomplete mail.
On Friday February 19 2010 13:45:09 Petr Kobalíček wrote: > I hope that this is my last message about theming:) I hope not, since you provided some useful information :) > I'm creating new theme for qooxdoo that is free available on the net > and this message should be summary of my experiences of making and > using custom qooxdoo themes (and using default qooxdoo themes as > well). Thanks for sharing it. > Pros: > - Qooxdoo theming engine is cross-browser (good bye css hacks). > - Ability to create feel based on 'states' so themes can be quite > different and featured. > - Separation of colors, decorators and appearances (which combines > colors and decorators). > - Decorators are powerful. > > Cons: > - It's imposible to create new theme from the scratch. There is no > documentation how to do it, there is no documentation about standard > decorators, appearances, etc. This should be improved in the future. Right. There is documentation about the several themes, but not for the specific implementation. On the other hand: the themes document themselves in a way. If you need to create an own theme, you can either take a look at an existing one or check the appearance IDs at the API Viewer to create an appearance for each widget. > - There are not standardized decorator and color names (each theme is > different). Yes, because every theme has different requirements. E.g. the Classic theme is much leaner than the Modern one and defines less decorators. > - Themes are not easily switchable if application extend theme. Theme switch at runtime is not supported, sorry. > - Appearances code is big and sometimes the same things are repeated > again and again (I don't like copy-and-paste programming). There a reasons for this. Sometimes a complex widget is put together from several basic widgets and it is necessary that the complex one is repeating some infos in order to get the right appearance. That's because you don't want to change the appearance of the basic widget and change the appearance of other complex widgets also. Can you please post some examples? Maybe I overlooked some cases. > - Icon theme is part of theme, I think that this is wrong (icons are > just icons and they have to be applicable for each theme). Honestly there is an open bug for this: http://bugzilla.qooxdoo.org/show_bug.cgi?id=1446 I mean not to remove the icon theme as such, but to be able to decouple the icon theme from a specifc appearance theme. > Feature requests: > - Standardize qooxdoo Modern and Classic theme to use similar > decorator names for similar things and write these standardized > decorator names into documentation. I think that this is important > because it will be allowed to use decorators that not depend to > particular theme. Also standardize order of keys in Appearance.js so > it would be easy to use diff. I don't know it's a good idea to standardize this, because every theme has different requirements and e.g. the Modern theme has much more decorators than the Classic one, because it's more complex. > - Write appearance names and their purposes into documentation. The appearance names are defined by the widget and documented at the API Viewer at the "appearance" property. > - Write helper functions that will be used inside the big > Appearance.js to simplify theme development. I tried it, but I have > only few functions at this time (see here > http://code.google.com/p/qxet/source/browse/trunk/qxet/source/class/qxet/Ut > il.js) As mentioned above: please provide some examples. I think the repetition has its purpose. > - Remove icon theme from themes. Our aim is to unite everything which has to do with the visuals of the widgets. And icons are definitely part of it. Splitting icons into an own part is somehow misleading in my opinion. cheers, Alex ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
