Hi Petr,
On Monday February 22 2010 23:07:01 Petr Kobalíček wrote:
> > 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.
>
> I don't know where. I tried qx, qx.theme and all packages/classes
> located here and I didn't find the appearance IDs. Please can you post
> link where the IDs are?
Yepp, you can click e.g. at the Atom widget
http://demo.qooxdoo.org/current/apiviewer/index.html#qx.ui.basic.Atom
and navigate to the "appearance" property. There you have to click at the "+"
sign to show the detailed infos about the property. The "init" value reveals
the appearance ID.
> >> - 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.
>
> You are right there, but on the other hand there should be always some
> standard decorators. For example I think that buttons, menus, tabs and
> nearly all widgets can share some decorator names and there should be
> only variants to more specific theming. For example in classic there
> will be 'button', 'button-hovered', 'button-pressed', instead of
> 'inset', 'outset', etc. But this was only example, I think that it is
> possible in future to create some convention.
The main issue here is that e.g. changing "inset" to "button" leads into the
wrong direction, since the "inset" decorator is used throughout the classic
appearance theme from different widgets like textfield, iframe, spinner and
others to create a 3-D look.
> > Theme switch at runtime is not supported, sorry.
>
> I'm not talking about runtime switching, but I'm talking about loading
> or building time theme switching. If you extend some theme you closed
> door to use another. Currently I think that 99.9% of qooxdoo users are
> using Modern theme so this is not needed, but imagine situation that
> there is available 10 very good themes for qooxdoo, I think that many
> devs like the idea to build application that will support all of these
> (of course some loader stuff will be always needed, for example
> my.app.com/admin?theme=BlueSky")
>
> But I think that this is currently not important at all (there are not
> too much themes and nobody needed this).
The demobrowser supports a kind of theme switching with an URL parameter.
There the application (running in an iframe) is reloaded with a special URL
parameter to switch the theme. The thing is that if you like to support this
kind of switching you need to build the app twice/multiple times (1 version
for each theme). Only with this precondition you can switch the theme of your
app with a URL parameter.
> >> - 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.
>
> Sure,
>
> look at this function:
>
> style : function(states)
> {
> var decorator, textColor;
>
> if (states.checked && states.focused && !states.inner)
> {
> decorator = "button-checked-focused";
> textColor = undefined;
> }
> else if (states.disabled)
> {
> decorator = "button-disabled";
> textColor = undefined;
> }
> else if (states.pressed)
> {
> decorator = "button-pressed";
> textColor = "text-hovered";
> }
> else if (states.checked)
> {
> decorator = "button-checked";
> textColor = undefined;
> }
> else if (states.hovered)
> {
> decorator = "button-hovered";
> textColor = "text-hovered";
> }
> else if (states.preselected && states.focused && !states.inner)
> {
> decorator = "button-preselected-focused";
> textColor = "text-hovered";
> }
> else if (states.preselected)
> {
> decorator = "button-preselected";
> textColor = "text-hovered";
> }
> else if (states.focused && !states.inner)
> {
> decorator = "button-focused";
> textColor = undefined;
> }
> else
> {
> decorator = "button";
> textColor = undefined;
> }
>
> return {
> decorator : decorator,
> textColor : textColor,
> shadow : states.invalid && !states.disabled ?
> "button-invalid-shadow" : undefined
> }
> }
>
> and at this one:
>
> style : function(states)
> {
> var icon;
> if (states.checked && states.focused) {
> icon = "radiobutton-checked-focused";
> } else if (states.checked && states.disabled) {
> icon = "radiobutton-checked-disabled";
> } else if (states.checked && states.pressed) {
> icon = "radiobutton-checked-pressed";
> } else if (states.checked && states.hovered) {
> icon = "radiobutton-checked-hovered";
> } else if (states.checked) {
> icon = "radiobutton-checked";
> } else if (states.disabled) {
> icon = "radiobutton-disabled";
> } else if (states.focused) {
> icon = "radiobutton-focused";
> } else if (states.pressed) {
> icon = "radiobutton-pressed";
> } else if (states.hovered) {
> icon = "radiobutton-hovered";
> } else {
> icon = "radiobutton";
> }
>
> var invalid = states.invalid && !states.disabled ? "-invalid" : "";
>
> return {
> icon: "decoration/form/" + icon + invalid + ".png",
> gap : 6
> }
> }
>
> it's the same copy-pasted-modified pattern included many times in
> Modern and Classic theme. When creating my own theme this was very
> annoying to see so I created helper methods that will return me string
> based on these states.
Yes this looks like a bad pattern at first, but it has one big advantage: it is
nearly self documenting code. The way the code is structured you look at it
and know what's its purpose right from the beginning. Yes, it's more
descriptive, but this hasn't to be a disadvantage automatically.
> Alex, this is just suggestion how the code inside themes can be
> improved (and it also means that naming of decorators should be
> standardized).
Yes and I'm really interested in such a profound feedback. You created your
own theme and while doing this you stumbled upon some things you dislike. No
problem with that. Thanks for sharing this infos with us.
I just want to explain my point of view :)
> >> 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.
>
> A partially answered above, I mainly talked about sharing common names.
Which is not quite easily to achieve in my opinion, because the themes are
just too different in some cases.
> >> - 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.
>
> Like my answer above, I don't see any IDs there, list of IDs that
> theme must implement, etc...
True, there is no list of the IDs. Maybe this is point where we can improve
the documentation. An automatically generated list of appearance IDs would
help here, right? Feel free to open a feature request for this issue.
> >> - 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.
>
> Look at code I posted above, it can be rewritten like this:
>
> style : function(states)
> {
> return {
> decorator : SomeUtil.stateToString("button", states),
> textColor : ...,
> shadow : ...
> }
> }
> },
>
> and
>
> style : function(states)
> {
> var invalid = states.invalid && !states.disabled ? "-invalid" : "";
>
> return {
> icon : SomeUtil.stateToString("radiobutton-", states),
> gap : 6
> }
> }
>
> This was just example for to create name based on states (hovered,
> disabled, etc...)
This would indeed shorten the code, but it would be less descriptive in my
eyes. And the themes should be descriptive even if it's end up in more code
lines.
> >> - 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.
>
> I understand, but what exactly icon theme shares with theme? I
> understand that I cant replace decorators, because they are used by
> appearance, but icons? Icons are just icons:) Creating another
> property in generator called for example "ICON_SET" seems to me as
> better solution than assigning icon sets directly to themes.
There are part of the UI of a widget and part of the look of an app. This is
the main reason why icons are part the theming machinery.
> Here I also thing that for example tab-close icon shouldn't be taken
> from icon theme. In modern theme the icon looks great, but in classic
> theme it's disaster.
We are using different icon themes (Tango and Oygen) and rely on them. On the
other hand there shouldn't be a barrier to replace some icons. Another bug
report to open :)
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
