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

[Alexander Dymo]

On Sunday 24 April 2005 12:29, Jens Herden wrote:
> 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 ;)

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.

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

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.

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

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.

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

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

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

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

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

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

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

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.

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.

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.

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.

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

24) automatic backup
Yep, that's useful.

-- 
Alexander Dymo
ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine