Better toolview

[Andreas Pakulat]

On 29.11.10 20:20:39, Silvère LESTANG wrote:
> Hey,
> a lot of plugins and features (Build, Run, Debug, Test and Version Control)
> use the standardouputview for displaying what they need to display. But this
> toolview is quite generic and doesn't correspond to the needs of most of
> them, and thus make it difficult to users to understand the UI (the previous
> and next buttons doesn't always do something and the two buttons "Select
> activated item" and "Focus when selecting item" are difficult to understand
> and irrelevant sometimes).
> I try in the last few days to see if it was possible to improve the
> standardouputview to full fit the needs of all plugins and features but I
> arrived to the conclusion that it's useless as every plugins have a slightly
> different needs.
> So I proposed to create a new toolview for each plugins or features which
> need one, starting by the Build feature.
> I think we need to keep the previous and next item, remove the "Select
> activated item" and "Focus when selecting item" buttons and replace them by
> a warning and error buttons that we can toggle to display only warnings
> and/or errors. I make a little mock up here:
> http://www.kdevelop.org/mediawiki/images/b/b8/Build_toolview.png
> What do you think about that?

I agree with Aleix and Milian (and not just because I wrote that beast).
The main idea is that most of the things you mentioned (except
find-in-files these days) have much in commmon with respect to their
"output needs". Maybe I'm oversimplifying things, but all of them output
(huge) amounts of text-lines. Some want to enable functionality to jump
between points-of-interest in that text (compiler errors,
version-control errors, test failures). Some don't need that, like
Run/Debug output from the application. The reason for doing a single
view for all of them is that some of the problems that such output views
impose are hard to solve and hence should be solved only once.

That being sad, yes the actions should be disabled if they don't do
anything. Unfortunately there is currently no way to decide that easily
as we don't have any kind of focus-tracking in the platform. If there
were you could enable the actions only if the focussed view is a
standard output view and the underlying model supports the next/previous
feature.

The two toolbar buttons have been added when some users wanted that
focus always moves to the item when its activated and some didn't. And a
third group wanted it to be at least selected... So maybe there
shouldn't be an option for all of that, but IMHO focus should never be
moved by an application automatically (except maybe if all editors have
been closed).

Having said all that, maybe a simple widget instead of a complete
toolview factory would better fit the design idea. Then each plugin
could use the widget in its toolview, populate the toolbar itself and
decide itself wether it wants tabs or or "next/previous" buttons or
neither. 

So IMHO thats the direction in which the coding of the
standardoutputview should move, remove the toolview bits, leave the
global actions and provide a widget and hooks to connect such a widget
to the global actions.

Andreas

-- 
Perfect day for scrubbing the floor and other exciting things.