applet browser: code complexity in the data model

Ana Cecília Martins Barbosa anaceciliamb at gmail.com
Mon Jun 29 15:28:27 CEST 2009


Hi!
First of all, thank you for your feed back on the code, that was necessary
by now. As a freshgirl I need to be put in line by whoever feels like I need
to (mostly ivan feels like everyday (kidding!) :P) and that's a nice thing
to me cause: I can get better and used to the way you work here, and I feel
closer to all of this. :)

so .. code complexity.
>
> 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. :)

we should try and avoid the same situation happening again and keep the code
> as straight-forward as possible.


I swear I was trying!


> get rid of KCategorizedItemsViewModels::DefaultItemModel.


Ok. Agreed.

in fact, forget about PlasmaAppletItemModel being a QStandardItemModel. it's
> just overhead in this case: we already have a perfect container object. so
> PlasmaAppletItemModel (PAIM? :) should just subclass QAbstractItemModel.


In this case I have to override all the functions needed to make a model
work, right?
I didn't really get this... Why is QStandardItemModel overhead again? I
believe you, but just want to understand :)

next, get rid of PlasmaAppletItem. we don't need it.


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

then implement data() such that the index.row() refers the index in the
> plugin
> info list, and the column to the various bits of data.


This make all the sense and would be simpler and as useful as the
PlasmaAppletItem.
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'm quite happy and willing to work on this with you.


Cool! :D


> if you tell me what your
> working hours are, we can hook up on irc. the above is really 2-3 hours of
> work at most, however.


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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20090629/ee39c454/attachment-0001.htm 


More information about the Plasma-devel mailing list