Better toolview

[Milian Wolff]

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:
> > 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).

What selection? What is "it" that is activated?

> 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.

Or add the required configuration options like I proposed.

> 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


-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101129/3a4ce756/attachment.sig>