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

List:       kdevelop-devel
Subject:    Re: application view
From:       Alexander Dymo <cloudtemple () mksat ! net>
Date:       2004-04-02 21:38:26
Message-ID: 200404030038.27266.cloudtemple () mksat ! net
[Download RAW message or body]

On Friday 02 April 2004 19:41, Daniel Franke wrote:
> > Let's assume the QListView derived widget is replaced by
> > a widget created by konsolpart. When using parts/konsole as
> > a template, this will result in just another konsole -
> > ups, we didn't ask for that?!
Hmm, yes, another little embedded konsole ;)

> > Alexander, if I understand your suggestion correctly, by
> > using konsolepart you imply the following behaviour:
> >  * an empty application view at startup (no prompt)
The propmt wouldn't hurt.
> >  * the app may be executed within this konsole, external terminal not
> >    necessary * tools may be run within/from this console to gather their
> >    output
> > * inactive state: either clear or display last messages
Basically, yes.

> > Requested features:
> >  a. application view should allow to be cleared (#60058)
> >  b. multi-line selection and copy-paste support (#60671)
> >  c. open corresponding sourcefile if a output-line has file- and line
> >     information (#72076)
> >
> > Also nice to have:
> >  d. distinguish between cout/cerr (cin?) by different highlighting
> >  e. output filter: cout/cerr (similar to very/short/full output
> >     of messages view)
Yes, would be good to have.

> >  f. [together with (c)] output formats of tools may differ
> >     significantly, user-defined pattern-matching might be reasonable (in
> >     addition to capture-output-flag in tools menu)?
This can be complicated to implement. The idea is to have "tool output format
plugins" for makeview and for appoutputview. Elsewhere you'll end checking
regexps for all supported tools every time - we do it in make output now,
it's not that fast.

> > As far as I can see it:
> > Konsolepart provides (b), (a) might be achieved by submitting
> > the "clear" statement, (c) if and only if the output if buffered,
> > assumably it is (buffer access?).
> > [Assumption:] Most likely it will not be possible to
> > handle (d) and (e) with konsolepart as kdevelop will never "see" the
> > output, it will be written by the konsole itself and will not be
> > handled by the application view.
(e) can be partially implemented by using redirections in commands
like make n>m.

> > Therefore my suggestion: use makeviewpart/makewidget as template to
> > implement an application view that provides above features, since
> > most of these features have already been implemented there.
> >
> > Do you agree with this? Objections? Suggestions?
Hmm, it sounds like konsole would be too restrivtive for anybody except me :)
Then I have only one objection against QTextEdit in application output.
It can simply be too slow, especially with cout/cerr and tool output
formatting. The good thing about konsole is that it's fast and efficiently
handle large output.

-- 
Alexander Dymo
ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine

_______________________________________________
Kdevelop-devel mailing list
Kdevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]