[quanta-devel] first thoughts about Quanta -> KDevelop

[Andras Mantia]

Hi Jens,

 I've just found your mail (again).

I mostly agree with what you wrote there. Of course threaded parser will 
be a challenge for us, but together with you we might clean up it, make 
it more readable and logical. Another challenge will be to make the VPL 
a separate component that communicates with the parser using a clear 
interface. This is mainly because I don't know the VPL internals.
Other items:
- upload profiles: how would other KDevelop languages profit of it?
- bookmarks: I'm fine having the KDevelop style toolview, especially 
that it shows context information as well in a tooltip. You were right, 
that by improving it and providing a "comment" entry for each bookmark, 
it may even be used as the annotation view. And with the help of a 
toolbox (like the one in the Documentation view of KDevelop) it may 
even have a "Current File" and an "All Files" area. But in this case 
hand editing (outside of KDevelop/Quanta) of the files will break the 
annotations.
- scrip tree: I never used KDevelop's script support, so I don't know 
yet if it can be reused for Quanta or not. 
- files tree: KDevelop's File Selector and File Tree is a little bit 
different, but we can improve one of them. File Selector is not a tree 
like view (we might add that mode), while File Tree lists only the 
files under the project directory. None of them support the concept of 
top-level folders, which might be very useful (and I know that Quanta 
users use it, as there were requests about it).
- debugger interface / Gubed: Linus should comment about it. Would be 
nice if it could be ported though.
- preview: I don't know what you mean about the internal/external 
preview here, nor what's in the comment field about .desktop file. I 
believe that preview should be a language dependent plugin or 
integrated code.
- spelling: I think it's already dropped
- problem reporter: KDevelop already has one, but might not be enough. 
We will need to check it. Of course, our problem reporter must be 
independent from the structure tree. I already have ideas about it.
- abbreviations: if KDevelop's one cannot be integrated, a new one 
should be written. As I see it already can make a difference between 
file types, altough for us "forb" might mean something else in the same 
document, depending on the area where the cursor is.

With the rest I agree.

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/20050509/ca24e3b4/attachment.sig>