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

List:       kde-devel
Subject:    Re: a suggestion about themes
From:       "Jos Poortvliet" <jospoortvliet () gmail ! com>
Date:       2007-09-11 10:07:32
Message-ID: 5c77e14b0709110307s46711983kabb8ba0833cc14b4 () mail ! gmail ! com
[Download RAW message or body]

On 9/11/07, yitzchak schwarz <s.y.schwarz@gmail.com> 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:
>
> 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.
>
> 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.
>
> 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.
> 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.
> 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.

Hmmm, different approach for sure... Currently, KDE themes are C++
code. Some are working on a theming engine allowing to use
png/jpg/whatever to theme, and maybe SVG. You propose to describe the
theme with XML. Does this add to the above things? It's harder than
SVG/png, and less flexible than C++, I suppose...

But I think it would be possible to write a theming engine which uses
C++ to implement this for KDE in the future...
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]