[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