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

[Jens Herden]

Hi,

> > I made a document from my first ideas and want to invite you to read and
> > comment it. Please download:
>
> Heh, I obviously missed your mail too. Sorry for the late reply ;)

Fine for me, I just started to wonder when I saw the mail from Andras and now 
you :-)

> 1) There's no need to implement your own shell. In order to have the
> "Quanta" application you need only to implement main.cpp and one
> subclass of "ShellExtension" class as shown in
> http://kdevelop.org/HEAD/doc/platform/html/kdevshellsrc/html/index.html.
> Also a plugins profile should be created using kdevprofileeditor tool.

Yes, I saw this meanwhile myself and I also saw that all header files are 
installed so that I can create this outside of the KDevelop tree.

> 2) parser
> Yes, the parser should go tho the language support.

OK.

> 3) structure tree
> Structure tree would be the different plugin only if it is sufficient for
> it to communicate with language support using "Code Model". Code model is
> an abstract representation of the code. It can be extended to fit Quanta's
> needs, but it still have to stay "abstract".
> In case structure tree requires more tight communication, it should belong
> to the language support.

Then it must go into language support. But my idea is to have this a an option 
because I want to enable a kind of Quanta light. Some users are always asking 
what they can disable to make Quanta faster. And it would be nice if I could 
put this in a plugin that communicates with the language support. 
Is this possible? I should be able to get the Quanta language support part in 
a plugin and use some methods which are not part of the normal language 
support part API, right?

> 4) project management
> Yes. Currently new projectmanager interfaces are under development to
> make it easier to create project management plugins.

Good to know.

> 5) upload profiles
> 6) project views
> 7) team configuration / even configuration
> Don't know because I'm not familiar with that stuff you have in Quanta.

5) and 6) should be not that hard. I will try to implement 6) soon and then 
you can see yourself. 
7) might create headache because we detect several events (like file save, 
file open...) in Quanta and are able to perform actions if an event happens.

> 8) script tree
> It should probably be merged with our Scripting plugin we have in
> KDevelop > 3.2

I will see how I can do this.


> 9) files tree
> Fileselector should become the part of kdevplatform probably and be reused.

Fine. Currently we have some code to detect if project files are manipulated. 
That means if a project file gets moved inside of the project tree the 
projects gets updated. If a file is copied inside of the project tree the 
user gets an option to add this file to the project... Do you have the same 
already?

> 10) gubed
> Our KDevDebugger interface is pretty simple, it shouldn't be a problem to
> implement it. Debugger should be a standalone plugin though.

Yes.

> 11) plugins
> I'm not sure I understand what it is but all KParts can be loaded to
> KDevelop with just 2-5 lines of code (or automatically using mimetype).

Yes, I saw that this is possible and I was quite happy to see this. What we 
currently do is to load KParts for Link Checker, Cervisia, Image Map Editor 
etc. But I saw that you assume that one file is opened in one KPart only (I 
saw a function to get the corresponding part to an URL). This is not true in 
Quanta where we can use the link checker and the editor at the same time. But 
we have to rethink this for Quanta anyway because there is no syncing between 
the two parts, which might create data loss in some circumstances. 

> 12) extension of the properties dialog
> What are those extensions?

An extra page in the dialog with information about the number of lines and the 
images included in the HTML file. There is also a page with information about 
the size of an image, but this could be dropped because it is redundant. 

> 13) CVS support
> CVS/SVN/Clearcase/Perforce is for free ;)

Yes, one of the main reasons we want to switch :-)

> 14) User defined actions/toolbars
> Yes, that would be quite useful plugin.

Fine.

> 15) preview
> Yes, preview is a part of language plugin. You might want to use our
> KHTMLPart subclass which is capable of some useful menus.

Yes, it is now part of the language plugin, but I doubt that this is a good 
solution. At least the PHP language support would benefit from an independent 
solution too. 

> 16) VPL
> We have KInterfaceDesigner::Designer interface in KDevelop to load
> GUI designers. You might want to check if it can be used (extended).
> If the interface can't be set up, you could just put the code into language
> support plugin.

I will look into this, thanks.

> 17) document properties dialog
> 19) attribute editor in the toolview
> Dunno.
>
> 18) tag editor dialog
> Looks like language support feature for me.
>
> 20) documentation toolview
> It would be easy to write .toc files for KDevelop documentation plugin.
> It can be done even now.

Yes, we just have to care about small details. Like we can have a doc folder 
in a project that becomes automaticly part of the documentation right now. I 
am sure this is easy to solve.

> 21) templates
> Do you mean file templates?
> KDevelop does allowsseveral file templates to have one extension. For
> example, it's possible to create pascal file with .pp extension using
> pp/program and pp/unit template.

No exactly, Quanta's idea of templates is that in a subtree you find files and 
have some attributes which tell Quanta what to do with this file. This could 
be: open a new document based on the template (that is what you have now) or 
insert the content of the template in the current file or insert a link to 
the file or even create a whole site from an archive is possible.

> 22) problem reporter
> We already have several problem reporters which will go to the language
> support base implementation for KDevelop4. You will just need to reuse it.
> Also our problem reporters are not plugins. They are part of language
> support and it's likely they will stay there.
>
> 23) abbreviations
> No need to write new plugins, let's make sure we use the common one (maybe
> yours with DTEP support).

Sounds good to me.

> 24) automatic backup
> Yep, that's useful.


This really looks like a bunch of work. But I will travel to Andras in June 
for six weeks so that we can do it together.

Jens