Better toolview

[Silvère LESTANG]

On 29 November 2010 23:34, Andreas Pakulat <apaku at gmx.de> wrote:

> 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.
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>

Sorry to dig a old thread but I started to work on it and a lot of questions
pop up.

   - We can have 3 types of standardtoolview; one with only one output
   (OneView), one with many output in tabs (MultipleView) and one with a stack
   of output (HistoryView). In the last one, I didn't understand the meaning of
   the left & right blue arrows until looking at the code and I am certainly
   not the only one. So I think it will be better to have only the tab view for
   multiple output, as we know how many are open and we can close them. Are you
   ok if I remove HistoryView and modify all standardtoolview using it?
   - standardtoolview is used by kdevelop for Build, Run, Debug, Test and
   Version Control toolviews (called afterwards kdevelop toolviews) but can
   also be used by different plugins. So it's contains code specific to
   kdevelop toolviews and more generic code for every toolview which need to
   display a list of items. Do you think it would be better to make it more
   generic by removing all code specific to kdevelop toolviews? Them we make
   kdevplatform less linked to kdevelop and the plugin make more sense.
   - Andreas suggest that we removed the toolview bit to transform it in a
   widget. If we do it, we kept it as a plugin?
   - If I transform standardtoolview in a widget, do you think it can be
   good to have a mechanism somewhere to create toolview more easily that now.
   Currently we have to write a toolview factory, which I think is a little too
   heavy for what it does.

In any case I will add a method to add actions to standardtoolview, makes
optional the "Select activated item" and "Focus when selecting item"buttons
and adds an optional filter action to highlight items which match the
filter.

Silvère
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110115/9e6d81c8/attachment.html>