<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 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><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[0] <a href="https://dl.dropboxusercontent.com/u/96475234/settings.png" target="_blank">https://dl.dropboxusercontent.<u></u>com/u/96475234/settings.png</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* 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.<br>
<br>
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.<br>

<br>
Any comments on my completion and committing of this work by week's end? (then on to bugs/issues)<br>
<br>
[0] <a href="https://www.dropbox.com/sh/05zltx1653zaaiu/WY1f4PO7Z6" target="_blank">https://www.dropbox.com/sh/<u></u>05zltx1653zaaiu/WY1f4PO7Z6</a><br>
[1] <a href="https://github.com/dakcarto/Quantum-GIS/tree/labeling-gui_redesign2_2" target="_blank">https://github.com/dakcarto/<u></u>Quantum-GIS/tree/labeling-gui_<u></u>redesign2_2</a><br>
<br>
Regards,<br>
<br>
Larry Shaffer<br>
Dakota Cartography<br>
Black Hills, South Dakota<br>
</blockquote>
<br>
Cheers,<br>
<br>
Denis<br>
</blockquote></div><br></div></div></div>