[Panel-devel] minimization to taskbar

Aaron J. Seigo aseigo at kde.org
Wed Dec 5 17:42:32 CET 2007


On Wednesday 05 December 2007, Jason Stubbs wrote:
> On Monday 03 December 2007 02:35:48 Aaron J. Seigo wrote:
> > On Sunday 02 December 2007, Jason Stubbs wrote:
> I've changed function names to be a little more programmer-friendly, moved
> some stuff out of Widget and into Widget::Private and updated View too.
> I'm not sure there's much more that can be done with this line of attack.
> I'm particularly pleased with the simplicity of the tasks changes.

yeah, it's nice to be able to get this feature where needed without much 
effort indeed.

i keep trying to ignore the fact that it pretty well completely breaks with 
the whole model/view concept ;) but the world of x just isn't ready for the 
stuff we're pulling, i fear.

> > that said, i still think it is too expensive to do the bookkeeping in
> > each widget. if a widget is interested in tracking this information.
>
> It's actually not that high. The only (semi-)hot path affected is
> itemChange's ItemPositionHashChanged event which has this false condition:

there's also memory usage with an extra QList per widget. these things have a 
way of accreting into monsters (see Plasma::Applet ;)

> What SystemTray is currently doing with sceneRectChanged() would be
> heavier... I've attached debug output that shows exactly what's happening
> during startup. There's a lot less activity once plasma is up and running.

minimizing start up costs is important, of course. speaking of which (and 
probably totally unrelated to this thread) plasma seems to have slowed down 
on start up for me here. i need to do some cachegrinding i think.

> > i wonder if this shouldn't be a special subclass of Plasma::Widget that
> > can be used by those elements (taskbar entries, systemtray) that need it
> > without incurring the overhead penalty anywhere else?
>
> I guess this could be done by utilizing sceneRectChanged() in combination
> with event compression. I'm not sure that there's any third way for a
> widget to know if it has moved... Should I implement this and see how it
> goes?

well, how about we do this:

- commit the current patch so we have something that works. it's pretty clean 
looking at this point, and having something working is probably goal #1
- we can continue to R&D improvements at our leisure =)

-- 
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: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071205/bb4040f1/attachment-0001.pgp 


More information about the Panel-devel mailing list