[Qgis-developer] Better options dialogs

Fri Sep 7 16:48:24 PDT 2012

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?

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.

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.

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
>> ==============================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: collapse-mate.jpg
Type: image/jpeg
Size: 31204 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20120907/604408c4/attachment-0001.jpg>