Hi Alex,
On Mon, Feb 22, 2010 at 2:31 PM, Alexander Steitz
<[email protected]> wrote:
> 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.
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?
>> - 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.
>> - Themes are not easily switchable if application extend theme.
> 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).
>> - 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.
Alex, this is just suggestion how the code inside themes can be
improved (and it also means that naming of decorators should be
standardized).
>> - 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.
Answered below.
>> 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.
>> - 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...
>> - 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...)
>> - 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.
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.
> cheers,
> Alex
Thanks for reply:)
--
Best regards
- Petr Kobalicek <http://kobalicek.com>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
