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!
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
