[Qgis-developer] Grass toolbox cleanup round 2

[Tim Sutton]

Hi Tom

2008/7/26 Tom Elwertowski <telwertowski at comcast.net>:
> Tim Sutton wrote:
>>
>> I'm doing a second round of cleanups to the grass toolbox usability
>> issues and to do away with some of the bugs in trac. I'd like to
>> propose to do :
>
> UI changes often need to be experienced before comments can be made. Since
> things are starting to happen in the grass branch, I now have some comments.

Great thanks for testing out the branch.

>
>>  - make the modules list a dockwidget (see
>> http://www.flickr.com/photos/timlinux/2668750983/ and
>> http://www.flickr.com/photos/timlinux/2668750977/in/photostream/)
>
> Since a detached dock can't be pushed behind another window, it's size
> should be closer to a toolbar rather then a window. The icons and
> explanation box should be optional so that the dock can show just the module
> names; essentially it would be a text toolbar of module names.

I think removing the icons would upset the GRASS users (just my
feeling nothing concrete to back that up), though I would also prefer
to get rid of them. I could make the description box collapse away /
expand back and that seems like a good idea to me too. I generally
prefer it when apps dont have windows that can disappear behind the
main window. Anecdotally one of the most common issues I see novice
users have is dealing with windows that disappear out of sight.

>
> If there is some way to detatch it as a regular window, the current layout
> is fine. If not, I prefer either a minimalist dock of module names or the
> current design where the Toolbox command crates a regular window.

I think the way forward here would be to implement a small grass prefs
dialog where this behavior can be defined. It should be trivial to
have the toolbox as a window or a dockwidget - I'll look into it.

>
>>  - do away with the tree view altogether
>
> I like hierarchy though I'm not sure I need the current tree view. Using the
> dots in the module names might be good enough to create a tree. I prefer the
> tree over the filter because I prefer to explore by mouse rather then
> keyboard.

I'll look at experimentally creating an option to swtich between using
tree or list views. I also like your idea of using dots to determine
heirachy, once again not sure if grass users have a different opinion
on this. One argument against could be that the dot prefix e.g. 'r.'
may not be intuitive to novice users where as 'Raster' might mean more
to them. Simply addressed using a 'dot lookup table' though I guess.

>
>>  - give the grass console its own icon on the grass toolbar and remove
>> from the module list
>
> This is ok. Right now the console is appearing as a dock which is not ok.
> The console should be in a window which can be pushed behind.
>

Once again somehting that can be made optional window or dock -
informal feedback from others suggests they like it in dock mode.
Other applications I've used e.g. kdevelop, kate etc make use of this
same paradigm (shell in dock) and I've always found it to be a good
experience.

>>  - make grass tools pop up in their own window
>>  - make the grass browser its own window with its own toolbar icon.
>>  - make the grass tool window scrollable when it has long lists of options
>
> ok as long as these are real windows and not docks.

Yes I plan to keep the tools in their own windows but do away with the
tabbed layout (users complain when they have many tools open the tab
bar becomes too long for the window to fit on screen). Other users
have requested the mapbrowser go into a dock (though given the space
confines I dont know if its feasible).

>
>> Any comments?
>
> In general, putting things into separate windows is fine. Too many docks
> however feel like popup advertisements in browsers. They steal or cover map
> space and you have to actively work to keep them out of the way.
>
> My preferred work style is to have a variety of windows mostly behind my
> main window. They stick out of all sides somewhat like tabs. I click a
> window to bring it forward, do something, and send it behind again.
>

I have pretty much opposite view to you on this - I get irritated with
popup windows and prefer everything embedded in a single workspace. I
also tend to work with each application maximised so your approach of
bits of windows sticking out the back seems to rob real estate from
the main application window, but just in a different way.

> Docks vs windows, trees vs. filters, tabs in windows vs. multiple windows.
> Different folk have different preferences. Rather then having to choose, we
> should investigate how to provide both. Perhaps I'm reacting too soon but
> the dock approach doesn't feel right for me.

Right I agree the best way is probably to try to accommodate the two
different work styles / viewpoints we each represent. I don't believe
it will add much work to do so.

Many thanks for the feedback

Regards

Tim

>
> Tom
>



-- 
Tim Sutton
QGIS Project Steering Committee Member - Release Manager
Visit http://qgis.org for a great open source GIS
Blog: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net