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

List:       ktexteditor-devel
Subject:    Re: KTextEditor container extension
From:       Philippe Fremy <phil () freehackers ! org>
Date:       2007-08-12 14:45:03
Message-ID: 46BF1CEF.7050604 () freehackers ! org
[Download RAW message or body]

Dominik Haumann wrote:
>>> - 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?

They don't have to, they may wish to allow the vim-ism :q! or :q to be
supported.

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

No idea. Does this cleans up properly all the kpart stuff ?

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

I am not very familiar with kate. When is the command run ? Is it by
some explicit action from the user, or any text that the user types may
by a command ?

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

That's exactly the same use case. A script needs some kind of user
visible output, to report success or failures, or to display the result
of some kind of analysis.


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

Still not familiar enough with Command to understand if that would be
sufficient.

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

We are not there yet. Quitting may be an optional stuff, but the
MdiContainer and this DisplayOutputContainer are major needs in my opinion.


	Philippe

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