<div dir="ltr"><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal"><quote author="Alexandre Neto"></div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">If I may,</div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal"><br></div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal"></quote></div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal"><br></div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">Yes of course! This feedback is much appreciated.</div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">Having labeled a lot of data, I'm still not very sure  by myself of what I would prefer. When I feel weird to lose my labels customization when rolling back a symbol color, having a clutered UI with multiple undo-redo panels everywhere sucks t.</div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal"><br></div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">We chose the separated undo / redo approach because that's what was done for composer and styling, and we didn't feel mature enough on the specifications for a unified undo/redo stack for project editing.</div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal"> </div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">For instance, CTRL+Z is by default on data editing and feels as the natural shortcut for cancel. How should that behave in an edit session mixed with project modifications. </div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">Also, some actions need to be excluded from the undo stack at project level such as zooming, panning. There are already buttons for that, on we could end with enormous  and noisy stacks. Every undoable action also needs to be named in the queue to help user find its way in the history, and that can be a big work to clarify all that.</div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal"><br></div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">I would propose to launch a dedicated QEP with a 3.2 milestone so that we can discuss ergonomics and details separately. </div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">If anyone is interested in supporting that work, let us know. </div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">Thoughts ?</div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal"><br></div><div style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px;line-height:normal">Régis</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-22 18:20 GMT+02:00 Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 23 August 2017 at 01:03, Alexandre Neto <<a href="mailto:senhor.neto@gmail.com">senhor.neto@gmail.com</a>> wrote:<br>
> If I may,<br>
><br>
> I would prefer to have one global undo/redo stack of buttons for all project<br>
> related tasks in QGIS main window (this should include labels, styles,<br>
> layers order, layer adding and so on). Even if that means that if you go<br>
> back too much, you risk removing some layers from the project, or other more<br>
> destructive actions. IMHO, having segmented undo/redo will also create<br>
> confusion among the users. Map composer, as a different window is the<br>
> exception, and should work separately.<br>
<br>
</span>+1, especially keeping composer undo stack separate<br>
<span class=""><br>
><br>
> Thanks for the work on auxiliary data storage, that will be great!!<br>
<br>
</span>+100<br>
<span class="HOEnZb"><font color="#888888"><br>
Nyall<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Alexandre Neto<br>
><br>
> Régis Haubourg <<a href="mailto:regis.haubourg@gmail.com">regis.haubourg@gmail.com</a>> escreveu no dia terça, 22/08/2017<br>
> às 14:47:<br>
>><br>
>> Hi all,<br>
>><br>
>> one major drawback of QGIS has long been that labeling was considered as<br>
>> part of the datasources, which can be true in some cases, but often it more<br>
>> belong to a project map object<br>
>><br>
>> We, at Oslandia, working on adding Auxiliary storage capabilities to QGIS,<br>
>> which was discussed in several QEP [1] before.<br>
>><br>
>> Now we are close to merge but the work but I would like to discuss some<br>
>> ergonomics and design polishing.<br>
>><br>
>> In all GIS tool, custom labeling informations have been stored in project<br>
>> file, except in QGIS (which was a brilliant idea to keep it simple !).<br>
>><br>
>> A user will now have two ways of storing labeling data :<br>
>>  - In the datasource by manually adding the fields and setting the<br>
>> corresponding labeling widget. Only advanced users, with grants on the<br>
>> datasource do that<br>
>> -  Using an auxiliary data source sqlite db stored inside the project,<br>
>> just directly using the labeling toolbar, even on readonly layers. 90 % of<br>
>> the users will use that I think.<br>
>><br>
>> If we consider that a label modification (location, style, rotation ...)<br>
>> belongs to a project, then we save it when a user saves the project.<br>
>> If we consider it is belonging to the data, we save it with data save<br>
>> button.<br>
>> Rollback for data edits exists using the edit buffer.<br>
>> But Rolling back project modifications exists only partially, in<br>
>> composer's edit command list or in dynamic styling panel.<br>
>><br>
>><br>
>> Our concern is about how to handle and display the undo/redo actions for<br>
>> labeling when they are stored inside the project file.<br>
>><br>
>><br>
>> We thought about 4  ways before concluding that:<br>
>> - merge the labeling command in the source layer's edit buffer stack -><br>
>> that won't work if the layer is readonly. If a user chose not to use the<br>
>> auxiliary data, then it will work like normal editing.<br>
>> - add separate buttons to save auxiliary data by hand (which is the same<br>
>> action as saving a project in fact). Tollbars are too cluttered and users<br>
>> are already confusing data and project save buttons.<br>
>> - Create a global "project" or maybe "mapcanvas" level stack, but I<br>
>> suspect users would like to be able to rollback style, composer and labeling<br>
>> independently, when undoing some labeling action could also remove some<br>
>> layers or important styling things.<br>
>> - Finally, we decided to add a separate edit buffer for the auxiliary data<br>
>> inside the dynamic styling panel, just below the style/label edit buffer.<br>
>><br>
>> So  has anyone any strong opinion here?<br>
>><br>
>> Is there any plan somewhere for a Project Undo/Redo, allowing for instance<br>
>> to Cancel a layer deletion ?<br>
>><br>
>> If yes, please share your thoughts so that we store each undo/redo stack<br>
>> at the right place, and hopefully with something users will understand<br>
>> easily.<br>
>><br>
>> All the best,<br>
>> Régis<br>
>><br>
>>  [1] <a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues/27" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-<wbr>Enhancement-Proposals/issues/<wbr>27</a><br>
>> ______________________________<wbr>_________________<br>
>> QGIS-Developer mailing list<br>
>> <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>
>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
>> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
><br>
> --<br>
> Alexandre Neto<br>
> ---------------------<br>
> @AlexNetoGeo<br>
> <a href="http://sigsemgrilhetas.wordpress.com" rel="noreferrer" target="_blank">http://sigsemgrilhetas.<wbr>wordpress.com</a><br>
> <a href="http://gisunchained.wordpress.com" rel="noreferrer" target="_blank">http://gisunchained.wordpress.<wbr>com</a><br>
><br>
> ______________________________<wbr>_________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
</div></div></blockquote></div><br></div>