[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: a suggestion about themes
From: "yitzchak schwarz" <s.y.schwarz () gmail ! com>
Date: 2007-09-11 21:35:12
Message-ID: 417207eb0709111435t5c3cc18fie86a0864bdbb5ff4 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
>
> 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 <<
>
additions and corrections to my original post:
button fields are GUI component fields.
image fields are realy just GUI fields, perhaps with less capabilities. -
possible merge.
images can have animation that can be controlled.
if there can be multiple animation sequences in a single image, even better.
GUI fields also have the value "tile and crop" for property "underflow".
"multi-element GUI container": holds multiple GUI elements, but displays
only one. property that holds the displayed element: representation.
possible implementation examples(for a single refresh/stop button in a web
browser):
<multi-gui name="stop-refresh">
<gui name="stp" class="stop" />
<gui name="rfrsh" class="refresh" />
<on-page-loading>
<representation class="stp" />
</on-page-loading>
<off-page-loading>
<representation class="rfrsh" />
</off-page-loading>
</multi-gui>
alternative 1:
<multi-gui name="stop-refresh">
<on-page-loading>
<representation class="stop" />
</on-page-loading>
<off-page-loading>
<representation class="refresh" />
</off-page-loading>
</multi-gui>
alternative 2:
<multi-gui name="stop-refresh">
<while-page-loading>
<representation class="stop" />
</while-page-loading>
<while-not-page-loading>
<representation class="refresh" />
</while-not-page-loading>
</multi-gui>
alternative 3:
<multi-gui name="stop-refresh">
<representation class="refresh" />
<while-page-loading>
<representation class="stop" />
</while-page-loading>
</multi-gui>
alternative 4:
<multi-gui name="stop-refresh">
<global-while-page-loading>
<representation class="stop" />
</global-while-page-loading>
<global-while-not-page-loading>
<representation class="refresh" />
</global-while-not-page-loading>
</multi-gui>
alternative 5:
<multi-gui name="stop-refresh">
<global-execute-all-while-page-loading>
<representation class="stop" />
</global-execute-all-while-page-loading>
<global-execute-all-while-not-page-loading>
<representation class="refresh" />
</global-execute-all-while-not-page-loading>
</multi-gui>
all options achieve exactly the same result.
0: creates local gui classes for the multi-gui, then uses them.
1: uses global gui classes.
2: uses a do-while loop. on-event(){do {stuff} while(the event didn't end)
or in plain english: when an event starts, it it performs all that stuff
once, then again and again until the event ends. for instance:
while-mouse-over would do stuff over and over again from the moment the
mouse hovers over the element until it moves away from it. when the loop
ends, everything reverts to what it was before the loop started. however,
since we have a complementary condition, while-not-page-loading, were
covered.
3: same here as in two, exept here instead of a complementary condition I
set a default, so it still behaves the same.
4: the use of the global suffix means all changes made in the loop are
permanent, thus requiring a complementary condition.
5: the "execute-all" suffix doesn't make any difference here, but it says
that everything will execute each time, even if no change occured between
executions. especialy effective with animations.
I forgot to add that GUI compositions (GUI elements) can be stored as
separate files, and imported as packages. they can also import other files
for the purpose of using the class provided. this allows for central control
despite breaking it down.
upsides for this theme format specification:
* easy to create GUI element themes from scratch. that is to say sets of GUI
elements, or "controls" themes.
* easy to create themes in general, not including fonts and icons.
* easy to modify and customize themes.
* extensible and reusable components.
* extensible format.
* GUI elemts are true 3D objects.
* built in transition animations for every event you care to make one for.
uses:
* building GUI elements.
* creating themes.
* creating GUI templates.
* creating application GUIs.
* creating applications. (with added support for a scripting language and a
backend such as C++ or PHP)
* can be used for multiple platforms, including desktop and web.
as an application GUI, it can be used with any graphical toolkit's API as an
implementation for an interface between the GUI and backend, allowing any
supporting desktop enviroment to use this as a GUI. this means identical
look and layout for an application no matter which platform it was written
for.
if implemented as a text-based format, it would allow to treat the interface
as a cusomizable theam. with scripting support, it would be easy to add
plugins and extentions, without any support needing to be written for the
application.
it would be possible to download and use any GUI layout and design you like
for an application, just like theming for a desktop environment that allows
to have different controls than the default as well as different looks for
the elements.
------------------
I hope this addresses what you were talking about.
[Attachment #5 (text/html)]
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; \
BORDER-LEFT: #ccc 1px solid"> <p>On 9/11/07, yitzchak schwarz <<a \
href="mailto:s.y.schwarz@gmail.com">s.y.schwarz@gmail.com</a>> wrote:<br>> I \
had last night an idea. why not make the creation of themed GUI elements<br>> as \
easy as possible? now, I don't know how things are done now, and as far <br>> \
as I know the current method could be light-years ahead of my idea, but here<br>> \
is the specification, as best I can write it:<br>><br>> base shape: a closed \
shape of of any number of lines. the lines can have any <br>> number of nodes to \
them. they can take any shape and corners can have any<br>> level of roundedness, \
so long as there is no overlap our crossing or<br>> touching.<br>><br>> top \
shape: identical to base shape, except: can have different size and <br>> \
position.<br>><br>> the nodes of the top shape are connected to their \
corresponding nodes in the<br>> base shape.<br>><br>> "the \
surfaces": each surface area on the top shape and the sides (but not <br>> \
base shape) has the following attributes: value gradient, color gradient. a<br>> \
group of surfaces can share gradients.<br>><br>> "the lines": each \
line has the following attributes: value gradient, color <br>> gradient. a group \
of lines can share gradients.<br>><br>> in addition, the theme \
determines:<br>> the color each class of surface.<br>> the color, style, \
and thickness each class of line.<br>><br> > the top shape can contain the \
following fields:<br>> text, image, button.<br>><br>> each field has the \
following attributes:<br>> position, size, overflow, underflow.<br>> \
position: top/bottom, left/right. <br>> size: width, height.<br>> overflow: \
crop, scale, scale proportionally, scale container.<br>> underflow: scale, scale \
proportionally, scale container, tile, position.<br>> crop: the content to be \
displayed is determined by specified position. <br>> scale proportionally: \
positioned within container as specified.<br>> position:<br>> \
top-left, top-center, top-right<br>> \
middle-left, middle-center, middle-right<br>> \
bottom-left, bottom-center, bottom-right \
<br>><br>> each field is rectangular.<br>><br>> each field is a \
class.<br>><br>> each text field has the following attributes:<br>> content, \
font-style, font-weight, font-size, font-color, text-line (for <br>> underline, \
strikethrough, etc), vertical-align, horizontal-align.<br>> in addition each text \
field might have the following overflow value (it<br>> might already be covered by \
crop, but then maybe it isn't. this should take <br>> serious \
consideration):<br>> hide.<br>><br>> each image field has the following \
attributes:<br>> class, package, file.<br>><br>> each button field has the \
following attributes:<br>> class, package, file. <br>><br>> important note: \
all classes are identified by index number, starting from 0.<br>><br>> \
events:<br>> these would cause changes in the appearance of the button, and \
therefor the<br>> button needs to determine it. <br>> the appearance of shapes \
and lines changes, so all class attributes must be<br>> determined for each event \
type. all normal class attributes are inherited by<br>> the event-specific class \
attributes, but can be overridden. <br>> event types: on-mouse-click, \
on-mouse-over.<br>> animations: the height of the top shape can be determined. it \
can be set<br>> separately for events as well. transition effects are simple: \
normal to<br>> on-mouse-click, normal to on-mouse-over, on-mouse-click to \
on-mouse-over. <br>> you simply have to determine the change-rate, that is, by how \
much should<br>> the the difference in the z-index be divided. then each level of \
z-index,<br>> from start to finish will be displayed. frame rate must also be \
determined. <br>> in addition, color transitions will be similarly \
animated.<br>> with lines, colored areas that overlap would have color transition \
only,<br>> while color areas that don't will fade out, and non-colored areas \
would fade <br>> in.<br>><br>> the two events presented here, on-mouse-click \
and on-mouse-over, are merely<br>> examples. any event can have a different \
appearance associated with it's<br>> occurrence. since all events inherit the \
normal state's attributes, nothing <br>> happens. however, if these attributes \
were overridden, then there would be a<br>> difference, and the above types of \
animations and appearance modifications<br>> would take \
place.<br>><br>><br>> ------------------------------- \
<br>><br>><br>> this presents an example of what an XML theme file might \
look like. I didn't<br>> include the icons, basically you just list the icon \
name according to the<br>> <a href="http://freedesktop.org"> freedesktop.org</a> \
specification, and the image file that would represent it.<br>> there would also \
be a shortcut by simply writing specifying a package. for<br>> example:<br>> \
<icon-set package="oxygen" /> <br>><br>> <import \
package-type="font" package-name="ariel" version=" 1.0" \
/><br>> <import package-type="icon-set" \
package-name="oxygen" version="1.0 " /><br>> <import \
package-type="button-set" package-name="gui" version="1.0 \
" /><br>><br>> <text name="txt1" \
font-style="ariel" font-weight="bold" font-size="12" \
<br>> font-color="rgba(150,150,150,100)" \
text-line="none"<br>> vertical-align="top" \
horizontal-align="left" /><br>><br>> <button \
name="but0"><br>> <line \
color="rgba(255,120,140,100)" style="solid" width="2" \
/> <br>> <fill \
color="rgba(140,120,255,100)" /><br>> </button><br>><br>> \
<button class="but0" name="but1" package="gui" \
file="button"><br>> <text \
class="txt1"> <br>> \
<content><br>> \
nothing noteworthy.<br>> \
</content><br>> \
</text><br>> <image package="oxygen" \
file="software" /><br>> </button> <br>><br>> \
-------------------------------<br>><br>> this is all intended to work with GUI \
tools. the button file would probably<br>> be SVG or something similar to that \
format.<br>><br>> I'd love to write it myself, except I'm still \
struggling to learn swing in <br>> Java. this is quite beyond me.</p>
<p>Hmmm, different approach for sure... Currently, KDE themes are C++<br>code. Some \
are working on a theming engine allowing to use<br>png/jpg/whatever to theme, and \
maybe SVG. You propose to describe the<br>theme with XML. Does this add to the above \
things? It's harder than <br>SVG/png, and less flexible than C++, I \
suppose...</p> <p>But I think it would be possible to write a theming engine which \
uses<br>C++ to implement this for KDE in the future...<br> <br>>> Visit <a \
href="http://mail.kde.org/mailman/listinfo/kde-devel#unsub">http://mail.kde.org/mailman/listinfo/kde-devel#unsub
</a> to unsubscribe <<</p></blockquote>
<div>additions and corrections to my original post:<br> </div>
<div>button fields are GUI component fields.<br>image fields are realy just GUI \
fields, perhaps with less capabilities. - possible merge.<br>images can have \
animation that can be controlled.<br>if there can be multiple animation sequences in \
a single image, even better. <br>GUI fields also have the value "tile and \
crop" for property "underflow".<br>"multi-element GUI \
container": holds multiple GUI elements, but displays only one. property that \
holds the displayed element: representation. <br><br>possible implementation \
examples(for a single refresh/stop button in a web browser):<br><multi-gui \
name="stop-refresh"><br> <gui name="stp" \
class="stop" /><br> <gui name="rfrsh" \
class="refresh" /> <br> <on-page-loading><br> <representation \
class="stp" \
/><br> </on-page-loading><br> <off-page-loading><br> <representation \
class="rfrsh" /><br> </off-page-loading> \
<br></multi-gui><br><br>alternative 1:<br><multi-gui \
name="stop-refresh"><br> <on-page-loading><br> <representation \
class="stop" \
/><br> </on-page-loading><br> <off-page-loading> \
<br> <representation class="refresh" \
/><br> </off-page-loading><br></multi-gui><br><br>alternative \
2:<br><multi-gui name="stop-refresh"><br> <while-page-loading><br> <representation \
class="stop" /> \
<br> </while-page-loading><br> <while-not-page-loading><br> <representation \
class="refresh" \
/><br> </while-not-page-loading><br></multi-gui><br><br>alternative \
3:<br><multi-gui name="stop-refresh"> <br> <representation \
class="refresh" \
/><br> <while-page-loading><br> <representation class="stop" \
/><br> </while-page-loading><br></multi-gui><br><br>alternative \
4:<br><multi-gui name="stop-refresh"> \
<br> <global-while-page-loading><br> <representation class="stop" \
/><br> </global-while-page-loading><br> <global-while-not-page-loading><br> <representation \
class="refresh" /> \
<br> </global-while-not-page-loading><br></multi-gui><br><br>alternative \
5:<br><multi-gui name="stop-refresh"><br> <global-execute-all-while-page-loading><br> <representation \
class="stop" /> \
<br> </global-execute-all-while-page-loading><br> <global-execute-all-while-not-page-loading><br> <representation \
class="refresh" \
/><br> </global-execute-all-while-not-page-loading><br></multi-gui> \
<br><br>all options achieve exactly the same result.<br><br>0: creates local gui \
classes for the multi-gui, then uses them.<br><br>1: uses global gui \
classes.<br><br>2: uses a do-while loop. on-event(){do {stuff} while(the event \
didn't end) or in plain english: when an event starts, it it performs all that \
stuff once, then again and again until the event ends. for instance: while-mouse-over \
would do stuff over and over again from the moment the mouse hovers over the element \
until it moves away from it. when the loop ends, everything reverts to what it was \
before the loop started. however, since we have a complementary condition, \
while-not-page-loading, were covered. <br><br>3: same here as in two, exept here \
instead of a complementary condition I set a default, so it still behaves the \
same.<br><br>4: the use of the global suffix means all changes made in the loop are \
permanent, thus requiring a complementary condition. <br><br>5: the \
"execute-all" suffix doesn't make any difference here, but it says that \
everything will execute each time, even if no change occured between executions. \
especialy effective with animations.<br> <br>I forgot to add that GUI compositions \
(GUI elements) can be stored as separate files, and imported as packages. they can \
also import other files for the purpose of using the class provided. this allows for \
central control despite breaking it down. <br><br>upsides for this theme format \
specification:<br>* easy to create GUI element themes from scratch. that is to say \
sets of GUI elements, or "controls" themes.<br>* easy to create themes in \
general, not including fonts and icons. <br>* easy to modify and customize \
themes.<br>* extensible and reusable components.<br>* extensible format.<br>* GUI \
elemts are true 3D objects.<br>* built in transition animations for every event you \
care to make one for. <br><br>uses:<br>* building GUI elements.<br>* creating \
themes.<br>* creating GUI templates.<br>* creating application GUIs.<br>* creating \
applications. (with added support for a scripting language and a backend such as C++ \
or PHP) <br>* can be used for multiple platforms, including desktop and \
web.<br><br>as an application GUI, it can be used with any graphical toolkit's \
API as an implementation for an interface between the GUI and backend, allowing \
any supporting desktop enviroment to use this as a GUI. this means identical look and \
layout for an application no matter which platform it was written for. <br><br>if \
implemented as a text-based format, it would allow to treat the interface as a \
cusomizable theam. with scripting support, it would be easy to add plugins and \
extentions, without any support needing to be written for the application. <br><br>it \
would be possible to download and use any GUI layout and design you like for an \
application, just like theming for a desktop environment that allows to have \
different controls than the default as well as different looks for the elements. \
<br> </div> <div><pre>------------------</pre><pre>I hope this addresses what \
you were talking about.</pre></div>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic