Quanta and the KDevelop framework
Jens Dagerbo
jens.dagerbo at swipnet.se
Wed Jul 27 22:42:17 UTC 2005
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
More information about the KDevelop-devel
mailing list