KDevFileManager performance

[Adam Treat]

On Friday 18 August 2006 9:31 am, Jens Herden wrote:
> On Friday 18 August 2006 06:54, Adam Treat wrote:
> > Hi!
> >
> > 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.
>
> So I understand now that this part of KDevelop is not yet really ready for
> usage by Quanta. Since I am right now at Andras place and we want to work
> as much as possible in the next days/weeks on Quanta we would have two
> options:
>
> 1. jump into KDevelop development and try to implement what is needed for
> Quanta
>
> 2. concentrate on Quanta internals that are more or less independed from
> KDevelop

This is what I think is best.  The API is still going through some big 
sweeping changes.  Personally, I think you should concentrate on Quanta 
specifics if you can.

> You could help us making this decision by answering the following
> questions:
>
> Do you want us to help in KDevelop? Even if we would need some guidance to
> fullfill a task?

Well, we have some definite plans already for the project API and for other 
parts.  Unfortunately the plans are mostly in other people's heads ;)

> Which areas in KDevelop are more or less stable already and could be used
> by us without the risk of many changes in the future?

The kdevplatform API is still subject to large changes.  All of it.

> Is there any estimation when the unstable areas in KDevelop might become
> stable?

Well, when the project stuff is converted to a true model/view and so on, then 
I would imagine the API's for that would take shape...

> Please understand that we do not want to put any pressure on anybody. We
> just try to get the most of our limited time.

Sure!  Most of the work right now involves changing our shared API's.  The 
easiest way to do this is just to disable everything else and worry about the 
core plugins.  We don't have the CPU cycles to test everything in Quanta when 
a change is made...  For now, if it is at all possible, can you guys 
concentrate on Quanta specific stuff?

BTW, I'm gone for the weekend camping.  Any replies will have to wait until 
Monday at the earliest...

Cheers,

Adam