new panel look and feel
Aaron J. Seigo
aseigo at kde.org
Sat Apr 19 14:25:08 CEST 2008
On Friday 18 April 2008, Marco Martin wrote:
> Hi all,
> as you may know, me and pinheiro are working on making a brand new look and
> feel for the panel, where the concept he is drawing is like he said on his
> message is this:
> http://www.nuno-icons.com/images/estilo/image7407.png
>
> now, in order to make it happen in a proper way, simply slapping a new svg
> theme isn't enough, some of the polishments we have in mind simply can't be
> done now, so we need some technical changes, i have written them down at
> the wiki page
> http://techbase.kde.org/index.php?title=User:Mart/PanelThemingTodo
> i'm pasting it here so it's easier to discuss:
>
> * two different svg element should be loaded by SvgPanel if the panel has a
> 100% width/height or not, because they need to use different illumination
> effects to look good
> ** another elementPrefix could be used or (i prefer) simply used the one
> without prefixes, that will also be used as fallback when north, south etc
> prefixes are not available
> This is the easy part, i will implement it right now if there aren't
> objections
>
>
> * tasks should draw their background with PanelSvg and there should be some
> sort of transition effect between two svgs when the task goes
> active/hovered
> ** maybe could it become too memory consuming?
if they share the renderer, it might be ok. there's really only one way to
tell, though and that's to try it. there should only need to be one svg
object per taskbar, however, and all tasks should share it.
i don't think SvgPanel will work out of the box for this, however. we probably
want a special SvgPanel (subclass?) or modify SvgPanel itself to support
multiple Panel items in the same SVG.
allowing PanelSVG to keep multiple items in the cache (so painting element1
then element2 then element1 again (typical usage in this sort of scenario)
doesn't result in creating a new pixmap and re-rendering every time)
> ** since complex transitions compositions probably are still far two
> PanelSvg will be needed that blend into each other
why wouldn't one svg be enough?
> ** elements we will probably need: active, inactive, iconified and
> requesting attention, each one with a normal and a mouse over version
could the hover (mouse over) version be achieved by painting an overlay of
some sort? that would cut the hover overhead to just one svg element and one
pixmap.
> *** maybe pixmap coloring for mouse over effects would be enough for now?
something to experiment with ...
> *** animation would only be needed for transition between mouse over and
> not for now, maybe other transitions will be implemented when we will have
> more complex timelines, like discussed with aaron and bibr at tokamak
this is just a pixmap<->pixmap blend, not hard to do.
> *systray should be able to draw a svg background too
> ** will also be a panelsvg but simpler without fancy animation effects
sounds good.
> * Desktop containment should be able to draw shadows for the panel views
i'm really, really hesitant on this one as doing it without really nasty hacks
that end up looking cheap will be hard. really, this should be done in kwin.
> * also breaking the model/view stuff, the panel containment should be able
> to set the shaped mask of the panelview window
as long as the containment has a proper shape() method, the view can query
that. no model/view breakage.
> and this could make the
> panel autohiding harder to do
not really
--
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/20080419/f6051422/attachment.pgp
More information about the Panel-devel
mailing list