new KDevPlatform API for consideration

[Jens Herden]

Hi Matt,

> > I wonder if some methods of KDevProject should better move into
> > KDevFileManager? I mean: inProject, absoluteUrl, relativeUrl. For me this
> > seems more natural to combine them there.
>
> inProject is a convenience method. absoluteUrl and relativeUrl refer to the
> project file as I understand it (and can remember w/o looking at the code)

you mean the .kdevelop file with project file?
If so, does this assume that the .kdevelop file is always in the top folder of 
a project? We had some complains about this limitation in Quanta. Some user 
want to store the project file independent of the project. I would love to 
have this possibility in the future. 
But then absolute and relative must be to the project root and not the project 
file. So it seems to fit better in KDevFileManager.


> > So maybe the best solution would be to drop KDevFileManager and put the
> > stuff directly into KDevProject? I mean can we imagine projects without
> > files? And even if there are some, they can carry the overhead.
> > What you would need than is a setBuildManager for projects which actually
> > support building.
>
> no, the whole point of KDevFileManager is to move all of that stuff out of
> KDevProject.  We just need to update the KDevProject docs. :)

Can you explain why you want to do this?


> > If yes, I am thinking about a way to associate custom data to a
> > KDevProjectItem. I mean like KFileItem is doing it. If we would have this
> > Quanta and others could use the default project of KDevelop and just add
> > pointers to specific data to the items. This would be very flexible and
> > could be used from different plugins at the same time.

You said nothing about this idea?

Jens
-------------- 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/20060523/7994dd0e/attachment.sig>