treat at kde.org
Thu Aug 17 23:54:30 UTC 2006
Can we please put off this discussion. There are bigger problems with the
project API(s) and they'll need to be completely refactored I'm afraid. This
is what currently happens:
KDevProjectController is the controller, but all it really does at the moment
is handle loading/unloading the KDevProjectManager_part.
KDevProjectManager_part is the view, but it calls the importers to populate
the data in a 'model'. This model really isn't a model at all. It needs to
be rewritten to inherit QAbstractItemModel.
Now, this is what _should_ be happening:
KDevProjectController is the controller and it should behave as such. The
controller should be primarily responsible with populating (via the
importers), updating and changing the project model. This model should
inherit QAbstractItemModel. The KDevProjectManager_part should only be
responsible for displaying the model. The only other thing it should do is
respond to user requests by forwarding those requests on to
KDevProjectController which should then update/change the model in accordance
with the user's requests. That is how it should happen.
Note that this isn't only the project API(s). The way KDevDocument is handled
is similarly messed up at the moment. Right now KDevDocumentController
behaves like a true controller, but it stores it's data in QHash(s). It
should directly populate a model that inherits QAbstractItemModel.
KDevDocument should be made to inherit KDevItemCollection and so on...
And then the DocumentView part should only be responsible for displaying the
model and forwarding on user requests to KDevDocumentController. Right now,
DocumentView tries to capture all the signals of KDevDocumentController to
populate it's own model. The view is playing intermediary between the
controller and the model. Bad!
So, as you can see all of this needs to be reworked. I have plans to do so,
but there are just so many things to do right now.
On Thursday 17 August 2006 3:57 pm, Andras Mantia wrote:
> I'm worried about the performance problems in the KDevFileManager
> class, due to the KDevProjectItem* way of storing the data. If these
> classes help later with the model/view stuff, I have no problem with
> them, but due to their tree-like structure it is hard and time
> consuming to work with them. For example if you want to get all the
> files that were added to the project, you would need to go through this
> structure using a recursive method. To find if a url was already added
> or not, you would have to do the same. To get information about the
> item, again, a search through all of the items.
> For this reason I have a suggestion, which is to move allFiles from
> KDevProject to KDevFileManager. The reasoning is that this way I could
> implement a file manager which stores the URL->KDevProjectItem* mapping
> in a QHash or QMap and it will be much faster to retrieve all the
> above. allFiles could have access directly to this map, inProject could
> get the QList of allFiles and find there the URL and so on. It would be
> even more better if allFiles would return a QHash<KUrl,
More information about the KDevelop-devel