OutputView behavior and usage
apaku at gmx.de
Wed Dec 5 17:11:37 UTC 2012
On Wed, Dec 5, 2012 at 4:30 PM, Ivan Shapovalov <intelfx100 at gmail.com> wrote:
> Recently I've been thinking about OutputViews and their "history support"
> (possibility to view old execution results) - esp. whether it is handy and
> convenient to use history abilities. And here are some points which seem
> inconvenient to me.
Since I wrote most of the initial code and came up with the types of
views, I guess I should add some comments.
> 1. The MultipleView's behavior of opening a new tab on each job can be pretty
> annoying, especially when the same launch configuration is being ran multiple
> times (debugging, etc).
> So I propose the following modification: make the tabs reusable (say, by name)
> + add an ability to "pin" an arbitrary tab to avoid reusing it.
I personally think that this should rather be some kind of
MultipleHistoryView, i.e. a new tab is created per launch config and
that can have history. The intention for this is that sometimes its
useful to be able to look at the output of a previous execution of a
launch config. The history could probably be limited to 10 items or so
to avoid explosion of memory over time for keeping all the data. It
annoys me regularly that this is not possible in Eclipse. Keeping the
tabs (by having a MultipleView) makes it easier to handle multipe
launch configs at the same time, in particular interesting in cases
where multiple processes work together...
> 2. Default view types for standard toolviews could be slightly modified. For
> example, I'd like to make build views MultipleView. Also, if (1) gets
> declined, it would make sense to make run/debug views HistoryView.
Why do you want build output use multipleview (thats the tabbed one
IIRC, right?)? I don't think keeping tons and tons of tabs makes any
sense and I rebuild much more often than I run a process. Are you
constantly switching between two build outputs? Maybe whats really
needed here is also a multi-history-view, where each buildset item
gets its own tab and again has history.
The new type would probably need some API extension as well to make it
usable and to give the plugins more access to the model and how long
its kept etc.
More information about the KDevelop-devel