merge of kdev-nice-project planned for later today

[Andras Mantia]

On Monday 17 July 2006 00:33, Matt Rogers wrote:
> > 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.

Even if it isn't so, it could do the same as I would do in code: first 
add the folder, get the KDevProjectFolderItem and add the file. 

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

In the same place as the remove functions below: if a file is deleted, 
moved, or copied into the project directory from within the 
application, this operation is detected and the project file is updated 
accordingly. It is not done with KDirWatch and the benefit is that in 
case of move we can know exactly which file was moved around and there 
won't be any data associated with that file lost. The implementation 
detail is a similar way to KIO::NetAccess, so instead of using 
NetAccess::copy/move/delete, our "NetAccess" is used everywhere in the 
code.

> 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.

That is for sure needed.

> > 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.

Well, how it is intended to be used? ;-) The current KDevelop headers 
seem to have partly outdated documentation and redundant lines, so I 
may overlook some things.

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

It is in trunk/kdewebdev/quanta/lib/quantanetaccess.cpp.

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20060717/1176b62a/attachment.sig>