Plasma Themes (for all plasma devs)

Aaron J. Seigo aseigo at kde.org
Sun Apr 20 21:10:14 CEST 2008


On Sunday 20 April 2008, pinheiro wrote:
> A Saturday 19 April 2008 22:42:32, Aaron J. Seigo escreveu:
> > On Saturday 19 April 2008, pinheiro wrote:
> > > Please oooo please dont limit the stuf one can do in plasma, visualy
> > > speacking, maybe we can teem up artist and coders, wen a
> > > designer/artist wants to do somthing more complex...
> >
> > we know just how well that works for qstyles and kwin decorations, don't
> > we?
>
> I'm prety happy how it went with Andre, and how its going with Marco.
> qstyles and kwin decorations is a hell of alot more complicated the coders
> cant simply use a svg i make they have to turn it in to pure code. So alot
> goes away in the process. but we alrady know that don't we?
> But yeah in a perfect world/plasma plasma would be extremy simple and
> extremly flexyble so any one could do plasmoids using any grafical
> element/shape he would desire.
>
> > let's get serious here: these themes are not a product being developed in
> > house as a one-off for a product that is paid for because it'll end up on
> > some .com website.
>
> Being very serius, I dont understand what you meen.

it means that we don't have the luxury of teaming up a graphic artist and a 
developer (let alone more than one) very often. theming must not become a 
task that takes months and months of effort to get to "ok". theming must be 
available to mere mortals. 

> whta I try to do? stuf that looks good.

of course.

> the second thing i ask myself, can this software pull it off?

the question is what we are willing and able to pull off (which is 
*not* "anything and everything") and how we will get the software to do it.

> > the idea is to have a *lot* of them, not a couple of them.
>
> don't agrea the imposing limitations is a way to get more themes.

it absolutely is. the more effort it takes, the less people will sit down and 
do it. and that includes those paid to do it. it's a matter of available time 
and energy (or 'personal investment')

there's an optimization process here, though:

* if a theme takes 5 minutes to do, but can only look as good as kicker did in 
3.5 why bother?

* if a theme can do dancing bears on rolling balls with specular lighting, but 
it takes 6 months, who will bother?

so we want enough features to make the themes interesting and good looking.

but we don't want features that provides a small, or worse irrelevant, % 
increase in capability but cause a large % increase in required effort.

so it's a matter of ballancing the time/energy that is required to create a 
theme with what themes are capable of.

as long as we don't have a WYSIWYG designer that allows an artist to work 
independantly, there will *never* be:

* source code
* overly complex arrangements of elements in svgs

in the meantime we can approximate some code like control with render hints in 
the svgs and provide a moderate amount of complexity in the svg element 
arrangements.

> The fact remains that for each plasmoid some one creates more elements will
> be needed, (and couse plasmoids are scalable it will mostly be on powers of
> 9) 

this is *precisely* why i keep saying, even if people keep ignoring it ;) , 
that plasmoids *should* remain within the boundaries of standardized look and 
feel. things that don't fit into those boundaries probably do not need to be 
themes.

this is not an idea i've cooked up without some research. go look at what's 
actually available on apple.com for dashboard widgets and look for 
commonalities in design, if you would like a body of works to repeat my 
efforts on.

yes, this is the harder (for us) route to go as it means up front design work. 
but it will save us from the hell you describe above with an ever increasing 
number of theme elements ranging in all sorts of random directions.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080420/48ebf527/attachment-0001.pgp 


More information about the Panel-devel mailing list