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

[Larry Shaffer]

Hi,

On Mon, Apr 29, 2013 at 11:10 PM, Denis Rouzaud <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


[0] https://dl.dropboxusercontent.**com/u/96475234/settings.png<https://dl.dropboxusercontent.com/u/96475234/settings.png>
>
>
>> * Freshen up the current implementation to be cleaner and more flexible
>> with the API, and refactor QgsPalLayerSettings, QgsPalLabeling and the
>> canvas labeling tools to utilize the new data definition methods.
>>
>> I believe I can finish this by the end of the week. IMHO, it would be
>> very good to get labeling to this state for 2.0, current bugs and issues
>> notwithstanding. This will allow a reasonably functional and flexible
>> labeling system (with expressions), to be used while a much larger
>> rule-based system and refactoring is being worked on for 2.x.
>>
>> Any comments on my completion and committing of this work by week's end?
>> (then on to bugs/issues)
>>
>> [0] https://www.dropbox.com/sh/**05zltx1653zaaiu/WY1f4PO7Z6<https://www.dropbox.com/sh/05zltx1653zaaiu/WY1f4PO7Z6>
>> [1] https://github.com/dakcarto/**Quantum-GIS/tree/labeling-gui_**
>> redesign2_2<https://github.com/dakcarto/Quantum-GIS/tree/labeling-gui_redesign2_2>
>>
>> Regards,
>>
>> Larry Shaffer
>> Dakota Cartography
>> Black Hills, South Dakota
>>
>
> Cheers,
>
> Denis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130430/b0e38ce2/attachment.html>