another interesting bug.. this time performance related
chrigi_1 at fastmail.fm
Sat Feb 19 17:06:34 CET 2011
On Saturday 19 February 2011 15:03:23 Marco Martin wrote:
> On Saturday 19 February 2011, Aaron J. Seigo wrote:
> > hey all ...
> > here's another interesting little bug:
> > https://bugs.kde.org/show_bug.cgi?id=251786
> > it seems we have some excess cpu usage in the system monitor plasmoids.
> > needs some investigating, but it's certainly reproducable. if anyone
> > wants to take it on, that'd be awesome.
> > and in case anyone is interested what i'm doing (pffft, why :P ), i've
> > continued to work on both the calendar event layout and the tasks widget.
> > in fact, i came to the conclusion after wasting ~2 hours futzing with the
> > tasks plasmoid that the animated layout on top of QGraphicsGridWidget is
> > a failure. it's ok, and the code does some impressive things given the
> > limitations, but it's just not Good Enough(tm) and it simply _can't_ be.
> > so i've started working on a replacement for it. a properly animated
> > grid layout that's a subclass of QGraphicsLayout. fun.
> eh, will be fun, yeah ;)
> also the positioning in multi line is fun as well.
> and correct propagating of size hints without the possibility to access
> into qgraphicslayoutitem privates... ;)
> related note, on the search and lauch, since 4.6 where i dropped the
> qgraphicsgridlayout and position icons by hand without -any-
> qgraphicslayout, everything started to work magically better :p
Excellent. That damn layout is the reason why I constatnly failed to implement
properly animated d&d operations for sorting and grouping in the tasks widget,
until I finally became frustrated and gave up... =/
> crazy idea: what about qml-ifing the taskbar right now?
> since is the most complex applet will still be a c++ one (that would just
> show a DeclarativeWidget and nothing else)
> i have no idea how much work would take, the only hard thing seems to be a
> correct handling of grouping (i guess it will have to be written a
> qabstractitemmodel that maps to what libtaskmanager says)
> for the positioning and animate flowing there is *exactly* what we need
> the Flow positioner item, containing a Repeater hooked up to the model for
> the tasks, so there *could* be even less work in doing that rather than
> writing a qgrphicslayout subclass, that is the most hairy thing ever ;)
Writing models is also not exactly trivial, although my major experiences have
been with proxymodels, which is probably a bit more difficult (read: A serious
I was also thinking about creating a qml version of the tasks applet, and I
believe that creating a treemodel would really be the way to go (although I
don't know much about qml).
What I did with the GroupManager and the AbstractGroupableItems is basically a
treemodel, without using QAbstractItemModel, and I think with the help of
QAbstractItemModel it would end up a lot cleaner/standardized.
We could start by simply exporting a TreeModel from GroupManager
instead/additionaly to the rootGroup().
I don't think that I will have time myself to do it, but lets see...
> (on a related note, i almost have a working systray in pure qml, since the
> mobile one thankfully doesn't support the xembed icons, it may be usable
> soon there)
> Marco Martin
> Plasma-devel mailing list
> Plasma-devel at kde.org
More information about the Plasma-devel