[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Plasma Themes (for all plasma devs)
From: Jamboarder <jamboarder () yahoo ! com>
Date: 2008-04-19 16:49:48
Message-ID: 296478.35762.qm () web37308 ! mail ! mud ! yahoo ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Aaron J. Seigo <aseigo@kde.org> wrote:
> i think 81 is a bit much. Nuno tends to go for the moon on these things, which
> is good as it keeps stretching us, but we also need to provide some breaks
> for him sometimes ;) 9 items per edge is 36 ... forget shadows, etc. 36 is
> still large, but the strategy is:
> we support simpler themes with fewer elements in them by falling back,
> allowing those who care to to create complex themes full of elements and
> those who don't to create simpler themes with minimal numbers of elements.
I didn't get the 81element count either. I agree here. Not every theme must use \
four different panel rendering for the different corners. The complexity is there \
for those who desire it. Perhaps what may be helpful is to update techbase more \
help more easily identify simple versus more complex theming facilities. I'm happy \
to help with that.
> > - more and more prefixes
>
> this is due, at least in part, to the oddness of trying to get geometry
> perfect. i honestly haven't seen the need for all of this and am somewhat
> relying on the artists to give decent direction.
If my input counts for anything: Preserve the ability to create simple themes, \
easily, while providing a framework for those who want to build more complex themes.
> > And still, there is so much that can not be done with this ever-growing
> > implementation of themes.
>
> what in particular are you considering?
I don't expect Plasma theming to be Inkscape. There will be limitations no matter \
how complex a framework we come up with. I'm far from convinced that we've exhausted \
the current mechanism. If all we had was svgpanel theming, we would not have even \
exhausted even that. The vast dificiency right now has more to do with artwork not \
framework. Of course there are limitations (combined gradient and tiling comes to \
mind). But I'm far from convinced that we've exhausted what can be done artistically \
within the current limitations yet. This is not strictly an argument against \
expanding the framework (since i'm guilty of advocating such expansion), just a \
reminder for the sake of prudence.
As for coding, I sincerely hope we do not make it a requirement for theme authoring.
peace,
Andrew Lake
[Attachment #5 (text/html)]
<html><head><style type="text/css"><!-- DIV {margin:0px;} \
--></style></head><body><div style="font-family:times new roman, new york, times, \
serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; \
font-size: 12pt;"><div style="font-family: times new roman,new york,times,serif; \
font-size: 12pt;">Aaron J. Seigo <aseigo@kde.org> wrote:<br>> i think 81 is \
a bit much. Nuno tends to go for the moon on these things, which <br>> is good as \
it keeps stretching us, but we also need to provide some breaks <br>> for him \
sometimes ;) 9 items per edge is 36 ... forget shadows, etc. 36 is <br>> still \
large, but the strategy is:<br><br>> we support simpler themes with fewer elements \
in them by falling back, <br>> allowing those who care to to create complex themes \
full of elements and <br>> those who don't to create simpler themes with minimal \
numbers of elements.<br><br>I didn't get the 81element count either. I agree \
here. Not every theme must use four different panel rendering for the different \
corners. The complexity is there for those who desire it. Perhaps \
what may be helpful is to update techbase more help more easily identify simple \
versus more complex theming facilities. I'm happy to help with \
that.<br><br>> > - more and more prefixes<br>> <br>> this is due, at \
least in part, to the oddness of trying to get geometry <br>> perfect. i honestly \
haven't seen the need for all of this and am somewhat <br>> relying on the artists \
to give decent direction.<br><br>If my input counts for anything: Preserve the \
ability to create simple themes, easily, while providing a framework for those who \
want to build more complex themes.<br><br>> > And still, there is so much that \
can not be done with this ever-growing<br>> > implementation of themes.<br>> \
<br>> what in particular are you considering?<br><br>I don't expect Plasma \
theming to be Inkscape. There will be limitations no matter how complex a \
framework we come up with. I'm far from convinced that we've exhausted the \
current mechanism. If all we had was svgpanel theming, we would not have even \
exhausted even that. The vast dificiency right now has more to do with artwork \
not framework. Of course there are limitations (combined gradient and tiling \
comes to mind). But I'm far from convinced that we've exhausted what can be \
done artistically within the current limitations yet. This is not strictly an \
argument against expanding the framework (since i'm guilty of advocating such \
expansion), just a reminder for the sake of prudence.<br><br>As for coding, I \
sincerely hope we do not make it a requirement for theme \
authoring.<br><br>peace,<br>Andrew Lake<br></div><br></div></div></body></html>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic