kate part

[Richard Dale]

On Wednesday 19 December 2001 5:10 pm, Sandy Meier wrote:
> On Wednesday, 19. December 2001 01:48, you wrote:
> > Also I have an idea on how to get a kate part working, essentialy just
> > using the same technique as for the NEdit part and implementing it by
> > calling the appropriate Kate::Document Kate::View methods. Also not
> > really a big deal.
> >
> > MDI is a completely different animal and I do not fully understand what
> > all is involved with that. It seems like there is another interface to
> > be designed and implemented, not really in my line of interest.
>
> I think the "best" solution for the Gideon GUI would be:
>
> 1) droping the KEditor interface in Gideon (as suggested by Matthias) and
> using KTextEditor::Document (and the subinterfaces) and KTextEditor::View
> from the kdelibs.The nedit plugin and the simple editor (for testing) need
> a new implementation, but I think this isn't on the top of the priority
> list.
I agree that the interfaces in kdelibs/ktexteditor look more complete. The 
source files in kdevelop/keditor have names which end in '_iface.h' like 
undo_iface.h, which I find really ugly. The ones in kdelibs end in 
'..interface.h' with no underscore. 

Why don't they use slots/signals, along with Qt runtime metadata to discover 
which slots and signals an editor part implements? There are nearly 20 small 
brittle C++ interfaces in kdelibs/ktexteditor, and no use of the Qt dynamic 
runtime.

Also, they use non-standard doc comments, in editor.h:

  /**
   * \brief Query for an advanced interface
   *
   * Returns a pointer to a more
   * advanced document interface.
   *
   * \param ifname The name of the interface
   *
   * \return Pointer to the interface, or 0 if the document
   * does not provide that interface.
   */

Is this from doxygen? I don't mind whether we use @param or \param, but I 
really don't think we should use both. Is there a KDE coding standard on doc 
comments? I'm normally against forcing everyone to use common coding 
standards - whoever originates to code should be able to choose layout style, 
tab width etc. But doc comments are another matter - they affect the 
documentation which users of the code see, not just people who maintain it.

> 2) using QDockWindow for docking the treeview and outputview area (docking
> support is already available in QMainWindow so this shoudn't be a problem)
>
> 3) using QExtMDI for the document/view managing (editor,docbrowser,custom
> plugin views).
>
> Can we agree on this?
Yes, sounds good to me, although I'm still not sure what the technical 
problems of combining KParts and QExtMDI are. I searched google and found 
there was some discussion by Bernd and others about problems with KParts not 
getting view change notifications from QExtMDI. But I could only find a 
reference to the discussion in KDE kernel cousin, and not the actual text in 
the core kde development list..

-- Richard