Better toolview

Andreas Pakulat apaku at
Mon Nov 29 22:58:53 UTC 2010

On 29.11.10 23:40:18, Milian Wolff wrote:
> Andreas Pakulat, 29.11.2010:
> > 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:
> > >
> > > 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).
> What selection? What is "it" that is activated?

The selection in the outputview. I'm not sure of todays implementation,
but "back in the old days" it was an itemview and hence you had a
selection in it. You could select each individual line. But there was
also a way to 'activate' a line, IIRC it was with double-click (might be
using KDE's single-click setting these days) which went to the
corresponding source code in the editor.

Now once you have a selection in the listview, you can use the next/prev
action (including a keyboard shortcut) to jump through the list of
"interesting spots" in the output. When the "focus-item" option is
disabled and the "select item" option is enabled the next/prev won't
jump through editors, this way you could go several steps up/down before
activating the item using <return> and jump to the error you wanted to.
At least that was the idea I believe. But some people wanted next/prev
to always directly jump to the corresponding source file hence the focus

I'm not saying it was the best idea (I was still young you know ;) and
I'm not certain whether the other combinations of those options make any
sense usability wise.


Your analyst has you mixed up with another patient.  Don't believe a
thing he tells you.

More information about the KDevelop-devel mailing list