applet browser: code complexity in the data model

[Aaron J. Seigo]

On Monday 29 June 2009, Ana Cecília Martins Barbosa wrote:
> > the code structure of the old applet dialog was highly engineered with
> > several
> > layers of indirection in the code. it was not easy to get into and that,
> > coupled with "well, it basically works as it is now", is why it never
> > really
> > got much work done on it.
>
> Well, yes. It took me some good, good time to look into that. As I was the
> one to work with it, I really digested the code and made it my everyday
> reading. I was able to make some drawings out of the architecture of the
> code and some out of the execution flow and I almost post it on my blog
> (don't know why I didn't). But I was very happy to be able to understand
> the whole thing. I was reeally satisfied with that - ivan knows that. :)

indeed, good job with that. :)

> > as straight-forward as possible.
>
> I swear I was trying!

yes, you made some great progress.

> Whaat? I loved PlasmaAppletItem! I simply called
> applet.anythingyouwannaknow() and it would all magically come!
> No, I'm kidding. ->

;)

well, there is a more drastic approach, which is not to use model/view at all. 
just grab the list of applets, create one AppletIcon per entry and then 
hide/show them by iterating over each and comparing whether they match or not. 
then you'd be using KPluginInfo directly. but i don't think we need to go THAT 
far, because:

QAbastractItemModel::data returns a QVariant, so you could wrap the 
KPluginInfo in a QVariant and then instead of using PlasmaAppletItem use 
KPluginInfo.

> But what happens when I want to know how many of a certain applet is
> running? Or like the mock introduced: how many of and where are them?
> Wouldn't it be better if those informations were stored somewhere?

i've been hesitating on this point because i don't want to dash people's grand 
ideas .... but ... do we need to know how many are running? do we need to know 
where they are?

here's a crazy, crazy idea:

we make a table view and put it on another tab in the System Activity window 
that krunner shows. the data can be gathered using dbus once plasma has that.

then the add widgets dialog becomes .. well .. just an add widgets dialog.

the remove buttons ended up there because it was very easy in past times to 
completely LOSE applets and that was the only way to get to them. oi!

i think there's lots of work there besides tracking and removing applets.

> Well, from now to the day I get on the plane to go to aKademy I can't do
> much work.. There are 2 projects and 1 exam to do to the university untill
> thursday (I don't even know how am I gonna accomplish all of that). But
> after that it's total dedication to gsoc, so my working hours will be many
> and then we can combine the working hour :)
> Also, let's try to make good use of the Working Days on akademy!

great :) see you online then :)

-- 
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 Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090629/fb8c0bd6/attachment-0001.sig