application view

[Daniel Franke]

Hi all :)

You remember my post the day before yesterday? Maybe I didn't express
myself clearly? :)

I'd love to give kdevelop some of that time back it saves me during
development of my own tools. I don't feel confident enough to do the BIG
stuff yet, so I opted for some wishes which seemed not to much of an
effort to grant.

As described below, it would not be a major change in kdevelop, but still
a significant one. Therefore, before hacking away, I would like to know
whether you approve these changes - or not (maybe someone already working
on this?).

Any suggestions, hints, links, objections are welcome :)

Regards
	Daniel

>
> http://bugs.kde.org/show_bug.cgi?id=60671
>
> ------- Additional Comments From daniel.franke imbs uni-luebeck de
> 2004-04-01 05:06 -------
> I'm not too familiar neither with kdevelop sources
> nor with KParts, so please correct me if I'm wrong:
>
> 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?!
>
> Alexander, if I understand your suggestion correctly, by
> using konsolepart you imply the following behaviour:
>  * an empty application view at startup (no prompt)
>  * 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
>
> 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)
>  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)?
>
> 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.
>
> 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?