[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: Better toolview
From:       Milian Wolff <mail () milianw ! de>
Date:       2010-11-29 22:40:18
Message-ID: 201011292340.18423.mail () milianw ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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@milianw.de
http://milianw.de

["signature.asc" (application/pgp-signature)]

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel


[prev in list] [next in list] [prev in thread] [next in thread]