Adding SVG image operations?

Aaron J. Seigo aseigo at kde.org
Sat May 17 19:09:25 CEST 2008


On Saturday 17 May 2008, Riccardo Iaconelli wrote:
> On Wednesday 16 April 2008 23:06:22 Rafał Miłecki wrote:
> > Currently we use some hacks when using SVG images. Let me just call
> > analog clock's code:
> >
> > 1) For drawing hand we use QPainter trick. We save current QPainter,
> > then rotate it, then draw choosen hand only and after all we restore
> > QPainter status. Isn't this little complex?
> >
> > 2) For drawing text with current time we use QPainter::drawText(...).
> > This causes possibility of situation when text is in place which was
> > designed by SVG author for sth else. What's more, we have no idea if
> > style of font does fit to SVG image.
> >
> > I think it would be great if we could just modify (in buffer) some
> > code of SVG and redraw it.  Some examples:
> >
> > 1) SVG author places simple line in image:
> > <line id="MinuteHand" x1="50" y1="50" x2="50" y2="0" />
> > which results in vertical hand. We just move it when needed:
> > <line id="MinuteHand" x1="50" y1="50" x2="48" y2="5" />
> >
> > 2) Author places:
> > <text id="TextTime" x="35" y="165">23:59</text>
> > and we manage to update content of text element.
> >
> > In future we could do even more. We could define names of JavaScript
> > functions building some kind of API. For example function
> > "isTimeTextDisplayed(status)" that is called every time KDE user
> > change displaying time as text. In that way we let SVG author adjust
> > image depending on KDE user's settings. Example:
> >
> > function isTimeTextDisplayed(status) {
> >   if (status) {
> >     document.getElementById("foo").style.display="hidden";
> >   }
> >   else {
> >     document.getElementById("foo").style.display="";
> >   }
> > }
> >
> > Opinions?

making svgs in the themes specific to widgets or applets means pushing applet 
logic into themes. so then we'd have applets existing in two places (half 
here, half there), multiple points of scripting language support (huzzzah for 
$LANG[1] in the svg and $LANG[2] in the applet =/) and growing inflexibility 
on both sides.

people seem to think this would be more flexible, but it's not. in your 
example we suddenly have this support for isTimeTextDisplayed which creates 
certain assumptions on both sides of this interface.

the worse outcomes is that certain themes and certain applets will become 
dependant on each other.

there is really nothing that can be done on the theme side that can't be done 
on the applet side with decent api available.

> I'm just thinking of different svgs loaded conditionally depending on
> the formfactor, or on the size... that would make possible e.g. using
> the analog clock in the panel, being still able to read it. =)

we already have ways of allowing for this that don't require code in the 
themes.

it just means that you actually have to think about what is needed and then 
standardize it within the themes.

-- 
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/20080517/fe3af3a6/attachment-0001.pgp 


More information about the Panel-devel mailing list