OutputView behavior and usage
intelfx100 at gmail.com
Thu Dec 6 14:37:30 UTC 2012
On 05 December 2012 18:11:37 Andreas Pakulat wrote:
> On Wed, Dec 5, 2012 at 4:30 PM, Ivan Shapovalov <intelfx100 at gmail.com>
> > 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...
That's a good idea. Will try to implement.
> > 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?)?
That would make sense if (1) had been accepted.
> 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.
Right. If we'd have MultipleHistoryView, that would certainly be the best
outputview type for build jobs.
> 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.
Do you mean IOutputView? Yes, it will need some extension.
BTW - how do you think it'd be most convenient to do "history"?
Maybe a right-click on a tab which will activate a dropdown list?
More information about the KDevelop-devel