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

List:       ktexteditor-devel
Subject:    Re: Improving ktexteditor interface (patch included)
From:       Philippe Fremy <phil () freehackers ! org>
Date:       2007-08-23 8:42:15
Message-ID: 46CD4867.8010507 () freehackers ! org
[Download RAW message or body]


	Hi,

It's been 5 days and nobody answered. I interpret this as "nobody really
has an opinion about this to really comment on it".

The patch was discussed and approved on ktexteditor, so, if there is no
comment from kde-core-devel, I'll commit it on next monday.

That would be my first patch to KDE since 1999 :-)

	Philippe


Philippe Fremy wrote:
> 	Hi,
> 
> I propose the following patch to improve the ktexteditor interface.
> 
> The current ktexteditor interface is based on a master -> slave
> relationship. The kpart host decides what to do (open documents, open
> views, close them, ...) and the kpart component obeys.
> 
> When working with Yzis (a vi engine for text editing, see
> http://www.yzis.org ), this does not work very well because Yzis is not
> a good slave. It wants to do stuff on his own:
> - with :edit some_file.txt , the kpart wants to open a new document and
> a new view
> - with :bdelete, the kpart wants to remove a document and a view
> - with :bnext, the kpart wants to change the active view
> 
> The patch allows the kpart host to set a class instance, which can be
> used for kpart component to kpart host communication. The mechanism is
> based on qobject_cast - like other extension mechanism in ktexteditor -
> and allows for current and future extensions of the kpart host interface
> in a BC way.
> 
> The patch has been discussed on ktexteditor (hence the seventh
> iteration) and has the approval of the people there ( see
> http://lists.kde.org/?l=ktexteditor-devel&m=118724435408905&w=2 ).
> 
> The first extension supported is the MdiContainer, that allows the part
> to create views, delete views, create documents, delete documents,
> change and fetch the current active view. The extension mechanism is by
> definition completely optional for the kpart host.
> 
> The patch is BC. Eventhough we have an API freeze, I would like it to go
> into KDE 4.0 .
> 
> 	cheers,
> 
> 	Philippe
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> KTextEditor-Devel mailing list
> KTextEditor-Devel@kde.org
> https://mail.kde.org/mailman/listinfo/ktexteditor-devel


_______________________________________________
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]