Quanta and the KDevelop framework

[Jens Herden]

Hi all,

this mail is somewhat longer and is the essence of my attendance at the 
KDevelop conference in Kiev and my hacking meeting with Andras here in 
Romania. I am about to go back to Cambodia and we will summarise our problems 
in using the KDevelop framework we found so far in this mail.

But I want to start with saying that we are very happy with the framework and 
we could quite easily port Quanta code to KDevelop. We were able to produce a 
first working version during the last six weeks (see branches/work/kdevquanta 
in SVN). When we started we were not sure if we could reach such a good 
result. 

So thumbs up for KDevelop and now the list of open questions and requests for 
changes. Please bear in mind that all this is targeted for KDevelop 4.0.
We are not quite sure how we want to procede with this list. Our plans are to 
release a first test version of what we did together with Quanta 3.5 and we 
plan to create the first real release for KDE 4.0 This means we will not join 
yet the KDE 4.0 development until 3.5 was released. So we can start working 
on the mentioned issues then or other people can pick up them yet already.

1.	create a new file that is not in the filesystem

We miss a way to open a new file without creating it in the filesystem. We 
found an ugly workaround that does not really work nice. Our wish would be to 
pass an empty KURL to open a new texteditor.

2. 	remote file or projects

The framework use QStrings to store an absolute path for files or folders. 
This prevents us from creating remote projects. The framework should use KURL 
for all absolute paths.
E.g. in KDevProject the method projectDirectory should return KURL, 
isProjectFile() and relativeProjectFile() should use KURL. The first argument 
of openProject() should be KURL. 

3.	additional methods for the project handling

We could not find a method to close the open project and one to save the open 
project. Saving a project can be usefull after changes in the settings. 

4.	more signals in the interface

We would like to have new signals for aboutToSaveFile, aboutToCloseFile and 
aboutToCloseProject. 

5.	events

Quanta has a feature to create and react on special events inside of the 
application. We would like to implement a similar feature in the framework. 
It would work with QCustomEvents and would allow plugins to filter and react 
on events. 

6.	one URL in more than one part

The framework assumes that only one part can open the same url at the same 
time. This is a limitation which we must remove for Quanta, because the same 
document can be in the editor, the preview and a link checker at the same 
moment. 

7.	support for different kparts in the framework

For opening an url it is not enough to pass the url, we also need a way to 
specify which kpart should open this url. This means also we need to be able 
to find out which kpart has opened an url and save this information.

8.	disable plugins without the profile editor

currently the user can disable plugins when he/she uses a project but since 
Quanta does not depend on a project it would also be important to disable 
plugins without an project. A kind of dialog that only allows to disable 
plugins from the current profile.

9.	splash screen text has hardcoded colors

The splash screen class does not use the provided color parameter to render 
the text message.

10.	problem with configuration dialog

The config dialog does not display the first page, if the extension does not 
provide a global page for the application.

11.	modified on disc

The framework uses the kate part to get information if a document was changed 
on the disc. This does not work if no Kate part is used. The framework should 
detect this on its own.
The message about a change in disk does appear when the user saves the 
document. We would suggest to show this message when the document get the 
focus instead. 

12.	context menus

The current implementation for the context menu does allow to add entries to 
popup menus from other plugins. This works nice so far but has the problem 
that we do not know the source plugin. So we are not able to conditionaly 
show an entry for a file context. E.g. the tabbar has file context but we 
would not like to pollute this menu with all file context actions. 

13.	open project dialog

The extensions in the open project dialog are hard coded. Since we want to 
use ".quanta" as a new file extension with the KDevelop data structure 
internally we need a way to set the filter for the dialog to something else.




We are looking forward to a fruitfull cooperation 

Jens