[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ktexteditor-devel
Subject:    Re: KTextEditor container extension
From:       Dominik Haumann <dhdev () gmx ! de>
Date:       2007-08-02 19:29:14
Message-ID: 200708022129.14709.dhdev () gmx ! de
[Download RAW message or body]

On Thursday 02 August 2007, Joseph Wenninger wrote:
> Hi !
>
> Is it really needed to have a 	Containerbaseclass, which inherits QObject
> ?
>
> If yes than I think it would be better to name the Method addContainer.
> Otherwise you can only set one extension with one interface.
>
>
> I'd drop the base class and change the signature to
> setContainer(QObject*) Don't derive the interfaces from one base class
> Container.

Sounds good.

> This would have the advantage that the developer of the host application
> could do
>
> class MyExtensionClass: public QObject, public
> KTextEditor::MultiDocMultiViewContainer,public
> KTextEditor::SomeOtherContainerFeatures{
> Q_OBJECT
> Q_INTERFACE("org.kde.KTextEditor.MultiDocMultiViewContainer")
> Q_INTERFACE("org.kde.KTextEditor.SomeOtherContainerFeatures")
> }
>
> I think this is nicer as having some does_it_support() functions and it
> would be more futureproof.
>
> The kpart could check (m_set_container is the internal pointer set by
> setContainer)
> KTextEditor::MultiDocMultiViewContainer
> *mdmvc=qobject_cast<KTextEditor::MultiDocMultiViewContainer*>(this->m_set
>_container); if (mdmvc) {
> 	do something with it
> }
>
> KTextEditor::SomeOtherContainerFeatures
> *socf=qobject_cast<KTextEditor::SomeOtherContainerFeatures*>(this->m_set_
>container); if (socf) {
> 	do something with it
> }
>
> Could be that I'm talking rubbish, I didn't follow that thread too much
> and I'm currently a littlebit tired.
>
> Kind regards
> Joseph Wenninger
>
> On Thursday 02 August 2007 18:25, Philippe Fremy wrote:
> > 	Hi,
> >
> > Another patch. That one does not compile, I only want to validate the
> > API.

Let's put the source code of those stuff into only one header file called 
containerextension.h (just like CommandInterface + Command + 
CommandExtension are in commandinterface.h).

Please rename MultiDocMultiViewContainer to MdiContainer.

> > I took the design approach that you mentionned in the last mail,
> > similar to the CommandInterface.
> >
> > I made a distinction between a generic Container class that only serves
> > as default return type of ContainerInterface::container() and a given
> > extension.

At first glance, I like jowenn's suggestions. Other comments? ;)

> > The first extension is MultiDocMultiView (suggestion for better names
> > are welcome) but I have more extensions in mind:
> >
> > - one extension to allow the kpart to request the application to exit.
> > This to support :q in Yzis.

I disagree: Why do the KTextEditor interfaces (which are for _text_ editing) 
have to provide a function like quit?

Doesn't qApp->quit() do the trick?

KDevelop could also implement a KTextEditor::Command q which is added to the 
Editor via the CommandInterface. If the command is executed, quit. That 
requires yzis to implement the CommandInterface in a vim like mode, but 
that's possible I believe.

> > - one extension to allow the kpart to send output to the kpart host.
> > For example, if I execute a script in Yzis, it might make sense to
> > display the output in KDevelop output window instead of splitting the
> > current Yzis view.

Maybe, a similar use case: E.g. javaScripts in KatePart might report an 
error. Right now we kDebug() the error. in release mode, this kDebug is a 
noop and nothing is displayed. So we either have to use cout et al. or 
provide another way to display such information. (maybe this could also be 
done via a KTE::Command, which whould have to be in the official KTE 
interfaces, though, something like message passing extension, where you can 
register/deregister clients).

However: An interface for every feature in KDevelop (or Kate, or whatever) 
sounds wrong to me.

Finding a good solution is what needs to be discussed here on the mailing 
list, though ;)

Dominik

_______________________________________________
KTextEditor-Devel mailing list
KTextEditor-Devel@kde.org
https://mail.kde.org/mailman/listinfo/ktexteditor-devel
[prev in list] [next in list] [prev in thread] [next in thread]