Quanta and the KDevelop framework
jens at kdewebdev.org
Mon Jul 25 21:11:09 UTC 2005
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
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
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
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
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
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
More information about the KDevelop-devel