Quanta and the KDevelop framework

[Andras Mantia]

Hi,

 Thanks for your replies. Maybe we were not clear, but most of the 
problems we would like to see fixed in KDevelop4 (or however will be 
called), in 3.5 only those that are easy.

On Wednesday 27 July 2005 23:48, Jens Dagerbo wrote:
> 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.

Right now in Quanta we uses a malformed URL to make sure that a new 
file, which is not loaded from the disc has a KURL. Our url looks like 
"file://UntitledN". The benefits of this is that it is easy to see if a 
document was already saved or not. 

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

I don't see why it would need a modification in the plugins. I see that 
it is not possible to add a KDevProject::saveProject() method due to 
BIC issues, but this should not affect other plugins. If one wants to 
save, it uses this and that's all.

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

Oh, than that should be renamed. ;-)

> > 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
Yes, and this is what we should get rid of. The relation is really one 
to N. I'm OK with having a 1-1 relation between a document and a text 
editor, altough sometimes it's also nice to see the same document in 
different views.

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

We were thinking about how to do this and couldn't find it. One idea 
would be to extend the KPart class so it provides the name of the 
desktop file or the name of the library from which it was created. This 
way one could query the loaded parts about their origin.

> 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.
Fine for me, just that project specific plugins should not show up in 
that dialog unless a project is loaded.

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

I will look at this before 3.5.

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

Well, in the current Quanta we use our own method to detect 
modifications and our own KDirWatch object. This most of the time 
works, altough we have some missreports about the file has changed, but 
this should be solvable as I don't use a fool-proof method to detect if 
the file was really changed or not. Kate uses MD5 sums, and that is a 
very good idea. ;-) So I don't see a limitation in KDirWatch, but 
having a general KTextEditor interface would be much better as it would 
save us from coding the same thing again.

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

Right now it shows the "modified" icon in the tabbar as soon as it is 
modified, but that is not really visible. The real warning comes only 
on save. What we would like is not to show a messagebox as soon as the 
modification is detected, but show it delayed when the user switches to 
a document which was modified outside.

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

Maybe, this is also a solution. Yet in some cases plugins are really 
working on files, but their usage is different so putting every file 
related context entry in their context menu might be annoying. 
One way is to create more pre-defined contexts (like TabContext), but 
still might make sense to know the real source. 
Another thing I don't like in the context menus is that you have no 
control about how the menu will look like, leading to a mess. So if you 
have a plugin adding an "Open" entry to the FileContext and another one 
adding "Open with..." they might appear in completely different places, 
not one after the other.

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20050728/993a6272/attachment.sig>