'Re: a suggestion about themes'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: a suggestion about themes
From:       Sandro Giessl <s.giessl () lechner ! de>
Date:       2007-09-30 14:33:09
Message-ID: 200709301633.09592.s.giessl () lechner ! de
[Download RAW message or body]

On Tuesday 11 September 2007 11:24:58 yitzchak schwarz wrote:
> I had last night an idea. why not make the creation of themed GUI elements
> as easy as possible? now, I don't know how things are done now, and as far
> as I know the current method could be light-years ahead of my idea, but
> here is the specification, as best I can write it:

Sorry for the late answer but I just managed to look through kde-devel.

You might be interested in Cokoon. It's a themeing framework 
which aims at similar goals like your idea, such as XML themes being editable 
by a GUI tool. But it operates on a lower level, where I see it fit best into 
the current way of current KDE themeing. It mostly only covers 
presentation and data exchange with the theme engine (kde cokoon style, kwin 
cokoon window decoration, custom widget...). Things like text, animation 
or 'event' logic are up to the theme engine.
You can have a look at example themes in style/TestTheme and 
decoration/TestTheme
http://websvn.kde.org/trunk/playground/artwork/cokoon/
http://www.commit-digest.org/issues/2007-07-29/#2

> base shape: a closed shape of of any number of lines. the lines can have
> any number of nodes to them. they can take any shape and corners can have
> any level of roundedness, so long as there is no overlap our crossing or
> touching.
>
> top shape: identical to base shape, except: can have different size and
> position.
>
> the nodes of the top shape are connected to their corresponding nodes in
> the base shape.
>
> "the surfaces": each surface area on the top shape and the sides (but not
> base shape) has the following attributes: value gradient, color gradient. a
> group of surfaces can share gradients.
>
> "the lines": each line has the following attributes: value gradient, color
> gradient. a group of lines can share gradients.

If I understand correctly, lines are some kind of drawing primitives? 
Currently in cokoon, there is no such thing; there are only image-'Sources' 
(e.g. graphics files), sor 'Special Tiles' (drawing operations implemented in 
the theme engine).

> in addition, the theme determines:
> the color each class of surface.
> the color, style, and thickness each class of line.
>
> the top shape can contain the following fields:
> text, image, button.
>
> each field has the following attributes:
> position, size, overflow, underflow.
> position: top/bottom, left/right.
> size: width, height.
> overflow: crop, scale, scale proportionally, scale container.
> underflow: scale, scale proportionally, scale container, tile, position.
> crop: the content to be displayed is determined by specified position.
> scale proportionally: positioned within container as specified.
> position:
> top-left,    top-center,    top-right
> middle-left,    middle-center,    middle-right
> bottom-left,    bottom-center,    bottom-right
>
> each field is rectangular.
>
> each field is a class.

'fields' are called 'Tiles' in Cokoon, and 'class' corresponds to a 
tabular 'Layout'.

> each text field has the following attributes:
> content, font-style, font-weight, font-size, font-color, text-line (for
> underline, strikethrough, etc), vertical-align, horizontal-align.
> in addition each text field might have the following overflow value (it
> might already be covered by crop, but then maybe it isn't. this should take
> serious consideration):
> hide.
>
> each image field has the following attributes:
> class, package, file.
>
> each button field has the following attributes:
> class, package, file.
>
> important note: all classes are identified by index number, starting from
> 0.
>
> events:
> these would cause changes in the appearance of the button, and therefor the
> button needs to determine it.
> the appearance of shapes and lines changes, so all class attributes must be
> determined for each event type. all normal class attributes are inherited
> by the event-specific class attributes, but can be overridden.
> event types: on-mouse-click, on-mouse-over.

Cokoon has the concept of 'states'. All possible states are defined in a 
theme, and the theme engine knows which state to draw.

> animations: the height of the top shape can be determined. it can be set
> separately for events as well. transition effects are simple: normal to
> on-mouse-click, normal to on-mouse-over, on-mouse-click to on-mouse-over.
> you simply have to determine the change-rate, that is, by how much should
> the the difference in the z-index be divided. then each level of z-index,
> from start to finish will be displayed. frame rate must also be determined.
> in addition, color transitions will be similarly animated.

Cokoon doesn't handle state transition animations, but I already thought about 
handling animation in the CokoonStyle theme engine. The way of specifying the 
transitions sounds interesting.

> with lines, colored areas that overlap would have color transition only,
> while color areas that don't will fade out, and non-colored areas would
> fade in.
>
> the two events presented here, on-mouse-click and on-mouse-over, are merely
> examples. any event can have a different appearance associated with it's
> occurrence. since all events inherit the normal state's attributes, nothing
> happens. however, if these attributes were overridden, then there would be
> a difference, and the above types of animations and appearance
> modifications would take place.
>
>
> -------------------------------
>
>
> this presents an example of what an XML theme file might look like. I
> didn't include the icons, basically you just list the icon name according
> to the freedesktop.org specification, and the image file that would
> represent it. there would also be a shortcut by simply writing specifying a
> package. for example:
> <icon-set package="oxygen" />
>
> <import package-type="font" package-name="ariel" version="1.0" />
> <import package-type="icon-set" package-name="oxygen" version="1.0" />
> <import package-type="button-set" package-name="gui" version="1.0" />
>
> <text name="txt1" font-style="ariel" font-weight="bold" font-size="12"
> font-color="rgba(150,150,150,100)" text-line="none" vertical-align="top"
> horizontal-align="left" />
>
> <button name="but0">
>     <line color="rgba(255,120,140,100)" style="solid" width="2" />
>     <fill color="rgba(140,120,255,100)" />
> </button>
>
> <button class="but0" name="but1" package="gui" file="button">
>     <text class="txt1">
>         <content>
>             nothing noteworthy.
>         </content>
>     </text>
>     <image package="oxygen" file="software" />
> </button>
>
> -------------------------------
>
> this is all intended to work with GUI tools. the button file would probably
> be SVG or something similar to that format.
>
> I'd love to write it myself, except I'm still struggling to learn swing in
> Java. this is quite beyond me.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread] 