[Qgis-developer] Better options dialogs

Sat Sep 8 20:42:16 PDT 2012

Hi Etienne,

On Fri, Sep 7, 2012 at 5:48 PM, Etienne Tourigny
<etourigny.dev at gmail.com> wrote:
> Hi Larry
>
> On Fri, Sep 7, 2012 at 5:03 PM, Larry Shaffer <larrys at dakotacarto.com> wrote:
>> 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've just pushed an update to QgsCollapsibleGroupBox which should
> solve UI issues.
>
> Basically, I swap the checkbox primitive element for a right/down
> arrow primitive, using a custom QProxyStyle class. Turns out it's easy
> - when you know the tricks.
>
> I have tested this using Linut Mint 12 with Cinnamon, Mate, KDE using
> various QGis themes.
>
> I would appreciate feedback on the UI from various platforms /
> environments (gnome, kde, unity, windows, osx) etc.
>
> If anything looks funky please send me an email with environment
> details and a screenshot (off-list)
>
>>
>> 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
>
> I am not decided yet on how this should work. From an implementation
> perspective, it's much easier to show/hide the groupbox contents when
> the
> groupbox is checked/unchecked.  From a UI perspective, the idea is to
> draw an arrow (right/down) in the space normally reserved for the
> checkbox.
>
> Now would we like an arrow (to show/hide the groupbox) plus a checkbox
> (to enable/disable the feature) is up for discussion.
>
> Functionally, when a groupbox is hidden its elements are disabled (by
> nature), but that doesn't mean any changes to the values are not
> available.
> Let's say you change the extents, then hide the extents box - the
> changes should be effective. For other elements in the raster save as
> dialog (say the create options), not filling in anything has no
> effect, so why add a checkbox for it?

Because the checkbox itself is a parent control, and obviously
functions that way in QtDesigner. It can and is used as a master
on/off toggle for those sets of options, not just graphically, but in
code, often for saving as a master trigger in QSettings (e.g. should
the buffer be drawn or not?).

Not having one with the title would require an *additional* master
checkbox control (if that function is needed) inside the groupbox that
takes the place/function of the repurposed title checkbox. Why cover
up a perfectly reasonable, heavily used control?

> I don't see that having an extra checkbox would be necessary in most
> cases.  Also it might look a bit weird if you have some groupboxes
> with checkboxes and some without - the titles will not be aligned.

The titles are already misaligned if you have some groupboxes with
title checkboxes and some without.

> If a UI guru is willing to step in to implement that, then it might be
> possible - but I don't see how to do it easily. You have many
> different styles to accommodate, that might require a lot of tweaking.

I think the collapsible groupbox has a lot to offer across many
dialogs in the app. After sending you the stylesheet update, I created
an update to the QgsCollapsibleGroupBox class you started, adding
support for collapsing independent of normal groupbox controls [0].

The added benefit of this approach is that it is seamless inside of
QtDesigner. Once the QGroupBox is promoted to QgsCollapsibleGroupBox,
a developer can utilize all controls as normal. When compiled and used
in the app, the custom groupbox class then just adds the
'collapsibility' [1].

This also means to add the collapsibility to existing groupboxes will
only require promoting in QtDesigner, with no loss of functionality
for those that already utilize the title checkbox.

The small embedded stylesheet will probably need updated to have the
groupbox's top margin look reasonably the same across platforms; but,
other than that, it should work fine. Please test my branch if you
have time. Otherwise, I can commit it to master as something others
can test with nightly builds.

[0] https://github.com/dakcarto/Quantum-GIS/tree/collapsible-grpbx_w-chkbx
[1] http://www.youtube.com/watch?v=mHWL7XJf7FYY

Note: the edits to src/ui/qgsrasterlayersaveasdialogbase.ui where just
for testing, and would probably not be committed as is.

Regards,

Larry

> Etienne
>
>>
>> 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
>>> ==============================================