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

List:       ktexteditor-devel
Subject:    Re: KTextEditor container extension
From:       Joseph Wenninger <jowenn () kde ! org>
Date:       2007-08-02 18:56:46
Message-ID: 200708022056.46646.jowenn () kde ! org
[Download RAW message or body]

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.

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.
>
> 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.
>
> 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.
>
> - 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.
>
> Probably more will come as Yzis grows in capabilities.
>
> Comments welcome.
>
> 	Philippe

-- 
Microsoft is not the Borg collective. The Borg collective has got proper
networking.
_______________________________________________
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]