another interesting bug.. this time performance related

[Christian Mollekopf]

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 
PITA).
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...

Cheers,

Chris

> 
> (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)
> 
> Cheers,
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel