[Qgis-developer] Better options dialogs

Fri Sep 7 13:03:07 PDT 2012

Hi Tim,

On Fri, Sep 7, 2012 at 4:30 AM, Tim Sutton <lists at linfiniti.com> wrote:
> Hi
>
> +1 from me to go back to the left if you can manage the issues as
> mentioned by Alex.

OK. Probably next week I will commit the revisions for the app options
dialog, which can then be tested and critiqued, before doing any
changes to other option dialogs (vector, raster).

> ... On a more general note, we need to make an effort
> to compartmentalise advanced options away from simple ones and I would
> really like to see a new QgsPropertyList widget which behaves
> similarly to QtDesigners property lists, especially for places where
> we have reams of options. ...

This would be an interesting approach, though I see a couple of concerns.

* In QtDesigner, intrinsic input is validated, but not functional logic
* Not all options may graphically fit into a property-list style

Explanation: Designer's Property Editor widget works very well for the
parent-child tree of widget objects' properties; but, short of input
validation, it doesn't care if you input value that won't work (I seem
to do that a lot :^). All relevant object properties are shown and
always editable. There appears to be no functional option-choosing
logic, like when a user selects a radio button or check box and
another part of the GUI become disabled, etc. I guess if a MVC
approach were taken, it might be possible to develop a setup where the
shown widgets (complex view) in an options dialog were decided by a
controller, where you can define the functional logic and handle
filtering for sets (models) of project- and app-level preferences.

Sounds like a fair bit of work that would definitely help create a DRY
design, help devs, but possibly, in the end, not be much different to
the user, since the GUI stills needs the functional option-choosing
logic. Would be very nice to have more of a MCV setup to work with.

In the meantime, maybe we can start with something graphical that
directly relates to the user. Etienne recently introduced collapsible
groupboxes, which he used in the raster Save As... dialog [0]. The
custom widget currently doesn't work right, with some graphical
issues; but, once functioning properly across all platforms, it should
be IMHO a much better solution to hiding sections, like Advanced
options, and a viable replacement for interfaces usually handled by
toolboxes.

I find the latter to be very good thing. Toolboxes are a poor GUI
choice because they force the user to hide one associated option set
in order to see another. The collapsible groupbox would fit nicely in
a side-tabs->tab widget-w/ scroll areas->multi-groupbox layout. It
would overcome the main issue with that layout choice, excessive
scrolling.

However, with Etienne's collapsible groupbox, there appears to be an
if-opened-then-its-enabled approach. I feel the opening/disclosing the
groupbox should be separate from whether its title checkbox is
checked.

[0] http://dl.dropbox.com/u/4058089/qgis/collapsible-groupboxes.png

Larry

> ... If we implement QgsPropertyList it should
> make these kind of refactorings 'DRY*' in the future.
>
> * DRY == dont repeat yourself
>
> Tim
>
> On Thu, Sep 6, 2012 at 2:47 PM, Etienne Tourigny
> <etourigny.dev at gmail.com> wrote:
>> Hi Larry.
>>
>> I think it's a great improvement. In addition, I wonder if it would
>> make sense to have the text below the icons (perhaps as an option), in
>> order to save some horizontal space.
>>
>> Have you tried that?
>>
>> Etienne
>>
>> On Thu, Sep 6, 2012 at 6:36 AM, Larry Shaffer <larrys at dakotacarto.com> wrote:
>>> Hi Alexander,
>>>
>>> On Thu, Sep 6, 2012 at 1:02 AM, Alexander Bruy <alexander.bruy at gmail.com> wrote:
>>>> Hi Larry,
>>>>
>>>> as already was mentioned in this thread similar design of options dialog
>>>> was used several versions ago but then we switched to tabs. List widget
>>>> only with icons IMHO not user friendly, especially for newcomers.
>>>>
>>>> If icons will be with captions we again come to initial problem for translators:
>>>> translating some text when listbox is used is a real pain in some languages.
>>>> I think Jean-Roc Morreale can explain all problems for translators better.
>>>
>>> Thanks for the input. Might you be referring to
>>> http://hub.qgis.org/issues/2202 ?
>>>
>>> My proposed layout does not have that issue. The one for 1.6 used
>>> large icons with text that was center-justified and wrapped
>>> underneath, but had no means of increasing the overall width of the
>>> widget by the user. It appears the larger icons were to aid in that
>>> problem, but weren't enough for longer translations.
>>>
>>> In my layout, the use of a splitter, whose state can easily be saved
>>> to QSettings, allows for the width of the list widget to customized
>>> (and stay that way) for users of different locales. I have 3 more
>>> mockups to illustrate this [0]:
>>>
>>> app-options_nowrap.png - Shows how the splitter can be moved to view
>>> the whole option set label (note French substitution for Map Tools).
>>> Expanding the left column like this, while possible, uses more
>>> horizontal space than necessary. Horizontal scroll bar is still
>>> available.
>>>
>>> app-options_wrap.png - Shows the QListWidget's word wrap helping save
>>> some horizontal space. This is with 32x32 icons, which I would
>>> consider the largest for desktop (as with QGIS tool bars). Even larger
>>> icons could be user-/config-set for touch screens.
>>>
>>> Given the improved layout over v. 1.6's, I foresee no issues for translators.
>>>
>>>> ... List widget
>>>> only with icons IMHO not user friendly, especially for newcomers.
>>>
>>> app-options_tooltip.png - Shows the collapsed splitter, with only
>>> icons and tool tips. This is an optional user-adjusted (or possibly
>>> button-enacted) view where the list widget's minimum width is set to
>>> the width of the chosen icon size + some padding (with scroll bar
>>> taken into account, if shown). This is not a default, which would not
>>> be so nice for new users, as you noted. However, also note that with
>>> this icon-only, space-saving view a user is not being presented with
>>> anything less user-friendly than the many tool bar icons in the main
>>> interface, which do not have any labels at all, only tool tips.
>>>
>>> [0] http://dl.dropbox.com/u/4058089/qgis/options-dlgs/app-options_nowrap.png
>>> https://dl.dropbox.com/u/4058089/qgis/options-dlgs/app-options_wrap.png
>>> https://dl.dropbox.com/u/4058089/qgis/options-dlgs/app-options_tooltip.png
>>>
>>> Larry
>>>
>>>> 2012/9/5 Larry Shaffer <larrys at dakotacarto.com>:
>>>>> 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:
>>>>
>>>> --
>>>> Alexander Bruy
>>> _______________________________________________
>>> 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
>
>
>
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==============================================
> Please do not email me off-list with technical
> support questions. Using the lists will gain
> more exposure for your issues and the knowledge
> surrounding your issue will be shared with all.
>
> Visit http://linfiniti.com to find out about:
>  * QGIS programming and support services
>  * Mapserver and PostGIS based hosting plans
>  * FOSS Consulting Services
> Skype: timlinux
> Irc: timlinux on #qgis at freenode.net
> ==============================================