[Qgis-developer] Labeling gui redesign and expression-based data definitions

[Denis Rouzaud]

On 04/30/2013 07:02 PM, Larry Shaffer wrote:
>
> Hi,
>
> On Mon, Apr 29, 2013 at 11:10 PM, Denis Rouzaud 
> <denis.rouzaud at gmail.com <mailto:denis.rouzaud at gmail.com>> wrote:
>
>     Hi,
>
>     On 04/30/2013 04:11 AM, Larry Shaffer wrote:
>
>         Hi,
>
>         Similar to Borys' dilemma, I am try bringing the new labeling
>         features and gui to a reasonable release state, but need a
>         couple of days more to finish things up (excepting existing
>         issues, etc.).
>
>         I have added expression-based data definitions for labeling
>         (bringing functionally on par with current symbology
>         implementation), but need the rest of the week to clean it up
>         and fully turn it on for existing and missing data
>         definitions. [0] slideshow, [1] branch. Note: if you build
>         that branch, only new-style data definitions and the new tool
>         button work for a label's *font size*, all others are
>         currently broken/unimplemented.
>
>         Things left to do:
>
>         * Re-work current labeling gui (not very difficult, see last
>         slide in slideshow for older sample of how it will look). This
>         will include integration of the inline data definition tool
>         buttons, which not only give feedback on the state of the
>         definition, but also disable appropriate layer-level widgets
>         if a definition is enabled.
>
>
>     Would it be possible to integrate the left panel in the panel of
>     the vector layer properties as a tree widget, as we see in many
>     software [0]?
>     I think this would be much clearer and space saving but I
>     understand it won't be that straightforward in current structure.
>
>
> This should really be a separate thread, as it needs some real 
> discussion focus. The sample you show is from a program of 
> conceptually different functionality (a code editor?). I will try to 
> outline the way I approach this with regards to GUI decisions for 
> QGIS: based upon the temporal access need of an object's properties
>
> * Code editors*
> These are programs that offer a solution to a fairly linear workflow 
> with limited objects.
>
> Objects: app, project, document, code
> Workflow: app options, project options, write code, test code
>
> The most temporal object is obviously the code. After that, you may 
> occasionally need to adjust project object options. Whereas, the app 
> options are probably accessed infrequently. In other words, grouping 
> together many options works because access to them is generally 
> infrequent once the editor is set up.
>
> * QGIS *
>
> Objects: app, project, data source, layer, feature, composer, composer 
> item
> Workflow: app options, project options, data source options, layer 
> options, (then, many different directions)
>
> Because much of visualizing GIS data requires editing options, those 
> options associated with objects of differing temporal access need to 
> be visually isolated to increase functional day-to-day focus and 
> remove unnecessary clutter. Ideally objects of differing temporal 
> access should not be grouped or shown together, except where such 
> context shows a relationship. For example, objects of a highly 
> temporal nature, e.g. symbology, labels, composer items, can be shown 
> within or associated with their parent object (and currently are).
>
> Since workflows in QGIS are so numerous, a more modular, rather than 
> always-grouped approach is better. For example, while doing a lot of 
> labeling, I prefer to just open the labeling dialog and not the vector 
> layer properties (which has the labeling dialog also embedded), to 
> reduce visual distraction and focus on the task. I would dislike being 
> forced to always wade through a layer dialog's tree just to do 
> labeling, and hate it if the layer dialog was also inside an even 
> larger tree structure.
>
> Similarly, there are some options dialogs that can be grouped but are 
> also best to have the ability to be separate, e.g. snapping options. 
> This should be in Project properties, but also available in separate 
> dialog/dock, because of its higher temporal access needs during 
> feature editing.
>
>
> Concerning the labeling dialog specifically, as labeling becomes more 
> complex, i.e. rule-based, it approaches the same gui functionality 
> needs as symbology. Graphically moving in that direction for 2.0 
> allows users to become accustomed to such a gui. In other words, 
> eventually much of editing labels will resemble the workflow and 
> dialogs of editing rule-based symbology. In this regard, a tree view 
> within the labeling dialog makes sense, though embedding it within a 
> tree view for the vector layer does not, since the labeling tree will 
> become an editable 'stack' like the one in symbology.
>
> Following this logic, I would like to see the symbology dialog more 
> modular and directly accessible like the one for labeling, as its 
> access is just as highly temporal.
>
> Regards,
>
> Larry
>
Hi Larry,

Thanks a lot for this clear explanations.

I understand you want to open the labelling in a separate dialog.
My idea was to provide the way of nesting left panels: if you have a 
widget with a left panel which goes in another one with a left panel, 
then it is nested. But you still have the possibility of showing the 
dialog on its own.

Besides, if the labelling is moving toward a tree widget, then 
effectively it makes no sense.

Thanks again for the clarification,

Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130501/74380837/attachment.html>