From kdevelop-devel Mon Nov 29 22:34:21 2010 From: Andreas Pakulat Date: Mon, 29 Nov 2010 22:34:21 +0000 To: kdevelop-devel Subject: Re: Better toolview Message-Id: <20101129223421.GB9810 () trinity ! apaku ! dnsalias ! org> X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=129107074921143 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@kdevelop.org https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel