[Qgis-developer] Labeling gui redesign and expression-based data definitions
denis.rouzaud at gmail.com
Tue Apr 30 22:24:16 PDT 2013
On 04/30/2013 07:02 PM, Larry Shaffer wrote:
> On Mon, Apr 29, 2013 at 11:10 PM, Denis Rouzaud
> <denis.rouzaud at gmail.com <mailto:denis.rouzaud at gmail.com>> wrote:
> On 04/30/2013 04:11 AM, Larry Shaffer wrote:
> 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.  slideshow,  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 ?
> 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
> 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.
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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer