<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 04/30/2013 07:02 PM, Larry Shaffer
wrote:<br>
</div>
<blockquote
cite="mid:CA+nQOR9pXv9+fNK=MRkJ2PmQ5-WCFEuQnXqVQOtjLJ0eSbYm8w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
Hi,<br>
<br>
<div>
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Apr 29, 2013 at 11:10 PM,
Denis Rouzaud <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 04/30/2013 04:11 AM, Larry Shaffer wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
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.).<br>
<br>
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.<br>
<br>
Things left to do:<br>
<br>
* 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.<br>
</blockquote>
<br>
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]?<br>
I think this would be much clearer and space saving but
I understand it won't be that straightforward in current
structure.<br>
</blockquote>
<div><br>
</div>
<div>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<br>
<br>
</div>
<div>* Code editors*<br>
</div>
<div>These are programs that offer a solution to a fairly
linear workflow with limited objects.<br>
<br>
</div>
<div>Objects: app, project, document, code<br>
</div>
<div>Workflow: app options, project options, write code,
test code<br>
</div>
<div><br>
</div>
<div>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.<br>
<br>
</div>
<div>* QGIS *<br>
</div>
<div><br>
Objects: app, project, data source, layer, feature,
composer, composer item<br>
</div>
<div>Workflow: app options, project options, data source
options, layer options, (then, many different
directions)<br>
<br>
</div>
<div>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).<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Regards,<br>
<br>
</div>
<div>Larry<br>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
Hi Larry,<br>
<br>
Thanks a lot for this clear explanations.<br>
<br>
I understand you want to open the labelling in a separate dialog. <br>
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.<br>
<br>
Besides, if the labelling is moving toward a tree widget, then
effectively it makes no sense.<br>
<br>
Thanks again for the clarification,<br>
<br>
Denis<br>
</body>
</html>