merge of kdev-nice-project planned for later today

[Matt Rogers]

On Sunday 16 July 2006 13:41, Andras Mantia wrote:
> On Friday 16 June 2006 15:20, Matt Rogers wrote:
> > Hi,
> >
> > I plan on merging kdev-nice-project back into kdevelop trunk sometime
> > later today or this weekend. It compiles and runs kdevelop and while
> > some things are missing, I'll be able to add them back quickly. I
> > also need more feedback on how the new API works when being used
> > rather than just a review.
>
> Ok, here are some comments. I find it harder to work with
> KDevProjectFileItem only instead of KUrl. For example, when adding a
> file there is a need to:
> - manually add the folder in which the file is, store the
> KDevProjectFolderItem, and use it to add a file by name. Instead of
> this, the API should be a simple addUrl() or if you want to avoid the
> ambiguity whether the last part of the URL is a file or folder, addFile
> and addFolder, taking only an KUrl.

It is not possible to remove the folder parameter for addFile or addFolder, 
respectively. The project list is no longer a flat listing of files. 

Where exactly do you need to use the add* or remove* functions? On initial 
project load, the import function should take care of everything. 

> - removeFolder or removeFile is even harder to use. For example, we want
> to detect if a file deleted is part of project or not, and if it,
> remove it. This is done in a library, which doesn't know much about the
> actual project, and until now if it was part of the project, we just
> called KDevProject->removeFile(url).  Now we should find somehow the
> corresponding KDevProjectFileItem for url, and this is not
> straightforward. Altough there is a KDevProject::inProject(KUrl), this
> is not enough, as it returns only a bool. The only way I could see it
> can be done is to use KDevProject::allFiles() and find ourselves from
> the list of KDevProjectFileItem objects the right one.
>  So either we need  KDevProject::itemForUrl(KUrl) or simple make the
> KDevFileManager work directly with KUrl objects.

detection of deletion will eventually be done via KDirWatch or a similar 
mechanism and should be handled automatically by the file manager for the 
project. 

I would prefer an itemForUrl type function if it's needed in other places.


> - a way to add multiple files at once is also missing. Not a big deal,
> but makes coding a little bit easier.
>



>
> Actually the above stops my current porting, as I don't want to do a big
> change in the code if we agree to introduce the KUrl argument way of
> handling. Is there anybody against doing so?
>

Yes, I am against it ATM, mostly because I don't believe you're using the API 
the way it's intended to be used. 

Do you have code that I can look at to see how you're doing things? 
--
Matt