[Bug 60671] Allow selection and copy in the application output view

Daniel Franke daniel.franke at imbs.uni-luebeck.de
Thu Apr 1 07:22:31 UTC 2004


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
      
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?




More information about the KDevelop-devel mailing list