[Icon Plasmoid] Provide a generic plasmoid class for icon based plasmoid

Aaron J. Seigo aseigo at kde.org
Sat May 31 22:41:44 CEST 2008


On Saturday 31 May 2008, Loïc Marteau wrote:
> Aaron J. Seigo wrote:

> > looking at your screenshot, i can see  what you are trying to do (make
> > all the icons similar/the same size) but this isn't the approach to take
> > as it doesn't follow
>
> What approach do you think is the better for plasma about this stuffs ?
>
> I would like to have icon plasmoid with the same default size (the same
> as the screenshot) perhaps 75 %
> but size should be configurable (by setting an other percentage in the
> class ?) .
> In the screenshot the K button is bigger than others and i think it's
> great to can do this.

i think this is really up to the Containment, in this case the Panel, to 
provide some mechanism for varying the size of select applets. perhaps 
something like zones of differing height.

sebas and alexis have both working on graphics items groupers that might be 
applicable in such situations.

> >> Question 4 :
> >> It is possible to reduce the width of unused space when we use the
> >> setAspectRatioMode(Plasma::Square) shortcut ?
> >
> > then it really isn't square, is it? =)
>
> Yes it is, sorry for my poor english. In fact i think that with this
> method (plasma::square) the width of plasmoid is well optimized and it
> is not the case of a lot of other plasmoids and we should fix this by
> providing a good (generic :op ?!) way to deal with this size problems.

> What do you think about proposing a recommended way to implement an icon
> plasmoid ?

that's probably a good idea.

> In fact there is still a space (too big imho) between each plasmoid. Is
> it possible to reduce it ?

the best way would be to ensure that each applet accurately reports the size 
it needs. this can be tricky with icons because they often have an unspecified 
amount of whitespace on their edges.

having them square ensures there is a consistent spacing of them, though due 
to the whitespace issue the apparent visual spacing may vary slightly. in the 
end it is up to the artists to ensure a reasonable centering of the image(s) 
that make up an icon.

> > in the case of the icons, we probably don't actually want to be using
> > Plasma::Square, but just set the size policy to be minimum for the growth
> > direction (horizontally on horizontal panels, vertically on vertical
> > panels)
>
> so isn't the idea to provide a generic class for them not good ? 

i'm just not sure how much code would end up being saved by this, since making 
an icon applet takes 6 lines of code: set the form factor to Square, create 
the Plasma::Icon, create a layout, set the margins and spacing to 0, add the 
icon to the layout.

if there was a generic applet, you'd still need to define which  icon by name 
to load, so we save 5 lines per applet. those 5 lines are not exactly tricky, 
and i don't think they justify having another library class.

what we *could* do, perhaps, it add another special constructor or method to 
Plasma::Icon that would put the icon inside a layout in the applet and make 
applets that are a simple icon based thing use that. even that's a bit 
drastic, but is a nicer solution imho than a whole new class.

also remember that some of these applets will expand to be more than just an 
icon when moved out of a Vertical or Horizontal Containment, and others, such 
as the battery which is essentially just an icon, need to do extra painting 
themselves anyways (such as on mouse hover in the case of the battery)... so 
the actual code savings would be pretty low and getting them all consistent 
isn't very hard ... =)

-- 
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/20080531/2909336b/attachment-0001.pgp 


More information about the Panel-devel mailing list