[Qgis-developer] Better options dialogs

Wed Sep 5 23:55:44 PDT 2012

Hi Larry,

+1 for vertical tabs.

In my opinion, vertical tabs provide an intuitive way of choosing the main category of interest, that uses the 2 dimensions on a screen better than horizontal tabs which expand foremost in one direction (The height of vertical tabs is smaller than the width of horizontal tabs).
Apart from that it leaves the horizontal tabs to the second-level dialog (diagrams in my case).

Some GUI's even use a tree widget to choose the main category (e.g. eclipse options). I would not prefer such an approach as it distracts the user and hides options he might be looking for. Just to have that one mentioned as well

I was actually thinking about the same thing but then told that the idea had been dismissed earlier (the one from 1.6)

Regards
Matthias Kuhn

> -----Original Message-----
> From: qgis-developer-bounces at lists.osgeo.org 
> [mailto:qgis-developer-bounces at lists.osgeo.org] On Behalf Of 
> Larry Shaffer
> Sent: Wednesday, September 05, 2012 11:41 PM
> To: Andreas Neumann
> Cc: qgis-developer at lists.osgeo.org
> Subject: Re: [Qgis-developer] Better options dialogs
> 
> Hi Andreas,
> 
> On Wed, Sep 5, 2012 at 2:14 PM, Andreas Neumann 
> <a.neumann at carto.net> wrote:
> > Hi,
> >
> > +1 for having icons with captions on the left. Some versions ago we 
> > +had
> > this idea already ;-) but with bigger icons.
> > see:
> > 
> http://en.wikipedia.org/wiki/File:QGis_Load_mapcolor_style_-_01_proper
> > ties_window.png
> 
> Well now, that looks familiar!  :^)
> 
> I pulled the .ui file from 1.6 branch and loaded into 
> Designer. Couple of differences between my layout and that one.
> 
> * Has no scroll areas for option sections
> * Icons too big @ 64x64 for desktop use (IMHO, it even makes 
> them look a little garish)
> * No splitter, though not really useful for that layout style
> * Unnecessary padding
> 
> Basically, though, the overall concept is the same. Icons 
> could be set to any reasonable (or device-specific) size in 
> the new layout via a pref.
> 
> 
> Little background on why I started looking into this today...
> 
> Matthias Kuhn on #qgis irc wrote [concerning his recent GUI updates to
> Diagrams]:
> > I wanted to use tabs instead of ToolBoxes, but it has been 
> suggested 
> > that tabs-in-tabs are a bad thing so second best possibility was to 
> > use ToolBox
> 
> No offense to Matthias here, but I find the toolbox approach 
> used in that layout to be unnecessarily confusing, with too 
> much hidden. A couple of tabs with scroll areas and group 
> boxes would not only match other layouts, it would work in a 
> smoother fashion (click-scroll).
> Toolboxes look OK on Ubuntu, but not so nice on Mac (Qt's 
> default toolbox approach is also very uncommon on Mac). When 
> a developer has to forgo an obvious GUI choice for good 
> organization of options, it says to me that the parent 
> control widget should be looked at for a fix, especially if 
> there are other added benefits.
> 
> Matthias should be able to layout the options for Diagrams in 
> a way he feels is appropriate, relative to the new 
> functionality of Diagrams and general HIG, or users may get confused.
> 
> While not using tabs within tabs is a good call, the more 
> complex QGIS becomes, the more the possibility of nesting of 
> options and controls will become an issue. Nesting the *same* 
> kinds of control widgets should be avoided. Mixing it up 
> graphically, if nesting is required, should be considered, as 
> well as approaches to parent control widgets that do not 
> limit the GUIs of their children.
> 
> Larry
> 
> 
> > see:
> > 
> http://en.wikipedia.org/wiki/File:QGis_Load_mapcolor_style_-_01_proper
> > ties_window.png
> >
> > Things are coming and going and coming back, it seems.
> >
> > Andreas
> >
> > Am 05.09.2012 21:55, schrieb Robert Szczepanek:
> >> Hi Larry and Marco,
> >>
> >> +1
> >> I have the same impression as you.
> >> Tabs to the left with captions. That would be great improvement.
> >>
> >> Similar discussion was recently on GRASS list [1]
> >>
> >> regards,
> >> Robert
> >>
> >> [1]
> >> 
> http://osgeo-org.1560.n6.nabble.com/command-dialog-notebook-styles-td
> >> 4997929.html
> >>
> >>
> >> On 05.09.2012 21:47, Larry Shaffer wrote:
> >>> Hi Marco,
> >>>
> >>> On Wed, Sep 5, 2012 at 1:26 PM, Marco Bernasocchi 
> >>> <marco at bernawebdesign.ch> wrote:
> >>>> On 09/06/2012 02:10 AM, Larry Shaffer wrote:
> >>>>> Hi,
> >>>> Hi Larry,
> >>>> Looks great to me, but not the version without text, too hard to 
> >>>> guess,
> >>>
> >>> The version with only icons is optional, and is produced 
> by setting 
> >>> an appropriate minimum width for the list widget. If a 
> user wanted 
> >>> to size it that way, it is possible (and a saveable 
> window state), 
> >>> but I am definitely not in favor of it being a default. 
> Thanks for 
> >>> the input!
> >>>
> >>> Larry
> >>>
> >>>> so +1 for me foremost for freeing vertical space
> >>>>
> >>>> ciao
> >>>> MArco
> >>>>>
> >>>>> I've been working on reducing overall clutter and excess space, 
> >>>>> and trying to increase efficiency and extensibility, 
> with options dialogs.
> >>>>>
> >>>>> Problems with current option dialogs' parent QTabWidget 
> approach:
> >>>>>
> >>>>> * Tab widget uses unnecessary vertical space (bad for 
> small screens).
> >>>>> * Tab widget limits the use of reasonably needed tabs 
> for option 
> >>>>> sections (avoiding tabs-within-tabs unfortunately 
> trumps useability).
> >>>>> * Horizontal parent tabs limit how many option sections can be 
> >>>>> offered (already too wide, without text truncation, on Mac).
> >>>>> * Horizontal parent tabs dictate the width of the 
> dialog, causing 
> >>>>> form layout elements to optically stretch too far apart.
> >>>>>
> >>>>>
> >>>>> Possible solution: Move 'tabs' to simple list widget on 
> left side 
> >>>>> of a splitter and have option sections loaded on right.
> >>>>>
> >>>>> I have done mockups for the app and vector layer options [0], 
> >>>>> which show the following advantages:
> >>>>>
> >>>>> * Vertical height is maximized without sacrificing layout of 
> >>>>> option section form elements (good for smaller screens).
> >>>>> * Number of option sections is not graphically limited.
> >>>>> * Number of option sections no longer dictates width of option 
> >>>>> section forms (forms look much better).
> >>>>> * List item widget can have its splitter section collapsed to a 
> >>>>> set size to show only icons for sections.
> >>>>> * Consistent look across platforms, with larger icons 
> for sections.
> >>>>> * More current 'look' for v 2.0 without too much work.
> >>>>>
> >>>>> Other than making the dialogs clearer and less 
> cluttered IMHO, the 
> >>>>> full useability of the dialogs at smaller sizes helps 
> the user see 
> >>>>> more map canvas when testing options with Apply.
> >>>>>
> >>>>> Any comments or suggestions?
> >>>>>
> >>>>> [0]
> >>>>> 
> https://www.dropbox.com/sh/yy0j3mmg4l4kw7x/Ar_S-eYqCv/qgis/options
> >>>>> -dlgs?lst
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Larry
> >>>>> _______________________________________________
> >>>>> Qgis-developer mailing list
> >>>>> Qgis-developer at lists.osgeo.org
> >>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Marco Bernasocchi
> >>>> http://opengis.ch
> >>> _______________________________________________
> >>> Qgis-developer mailing list
> >>> Qgis-developer at lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>>
> >>
> >> _______________________________________________
> >> Qgis-developer mailing list
> >> Qgis-developer at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 