Quanta and the KDevelop framework

[Jens Dagerbo]

Hi,

On Monday 25 July 2005 18:48, Jens Herden wrote:
> 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.

Yeah, we should really have this. I'm not quite sure about the consequences 
however. I suspect it will be related to the problems with #6.


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

Agreed. The slow port to KURL has been going on for quite some time. It was 
more or less agreed pre-3.0 that KURL would be better in most places but we 
focussed more on the stuff that wasn't working at all at that point..


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

True. But implementing saving plugin settings without closing the project will 
under the curent design mean modifiying all the plugins - probably too large 
before KDevelop4.

> 4.	more signals in the interface
>
> We would like to have new signals for aboutToSaveFile, aboutToCloseFile and
> aboutToCloseProject.

aboutToSaveFile and aboutToCloseFile should be easy to implement. 
aboutToCloseProject already exists - inconspicously named 
KDevCore::projectClosed(). ;)

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

This is unfortunate and needs a rethink for KDevelop4. I'm fairly sure it was 
I that added partForURL() and it didn't seem like a great idea at the time, 
but we already had code that assumed a one-one relationship between part and 
URL
.

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

PartController::editDocument() grows ever more complex.. and it still doesn't 
always do what we want. In part this is because the (KDE) mimetype<->KPart 
mappings have odd behaviour in places. This is a rather tough nut and I 
suspect will have to take into account whatever document manager / MDI 
framework we end up using in KDevelop4.


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

The plugin selection dialog is in the wrong place. It really should be in 
global scope. I always meant to move it there after we combined the two 
plugin selection dialogs but ran out of time. I'd prefer to move it out of 
the regular settings dialog too, but this has both pros and cons.


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

Right. We first noticed with the KDevAssistant application. It turned out to 
be less trivial to fix than I thought. The problem is caused by KDialogBase 
not emitting the aboutToShowPage() signal for the first page it displays. 
KDevelop listens to aboutToShowPage() and delays dialog page creation via 
ConfigWidgetProxy. Ideally this can be implemented in KDialogBase in KDE4 or 
we implement our own subclass and fix it there, if possible. 


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

Right. I wish it was simple though. Unless it has changed since I tried it 
(about a year ago) you can't have two subscriptions to KDirWatch for the same 
file from the same application without them causing trouble for each other. 
(I can go into detail if it's interesting.) I ended up using the Kate signal 
because it was there and at least we could get the feature working for the 
default editor plugin.

KDE4 scope: Define a KTE interface for the editor plugins to notify us, or fix 
KDirWatch so that we can implement it ourselves.


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

I think the (currently disabled) "alert the user" option brings up a 
messagebox when katepart detects it, not just on file save. This option 
currently crashes us if more than one file notification occurs at the same 
time. See http://bugs.kde.org/show_bug.cgi?id=97896. I believe Alexander 
Neundorf traced it to KDirWatch. This problem sadly renders the whole 
exercise rather pointless.


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

Isn't this the same as saying the contexts aren't granular enough? Too many 
plugins emit FileContext? I don't think the solution is to somehow add the 
information of what plugin is the origin of the context menu - plugins should 
react to context, nothing else. But I'd agree we've probably overused 
FileContext.


> 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

I'm optimistic. More developers active in the codebase can only be a positive 
thing. :)


// jens