|
|
123
|
|
Hi everyone
I have just merged the first part of the legend refactoring work to
master [1]. It does not really bring any new features for the end
user, the changes are mainly under the hood. Things should ideally
work as before, if not then probably it is a bug.
There will be second part of the work related mainly around improved
layer symbology display in legend, more interactive legend and more
options for customization. At Lutra Consulting we are still looking
for funders willing to co-fund the work. At this point let me thank
SIGE and Swiss QGIS User Group for supporting the project.
Please test thoroughly - the legend has received quite a lot of
features over time, so there could be still some minor features I have
missed to port to new implementation.
The format of the project file has changed, but there is backward
compatibility with older projects which should allow seamless
transition. Once saved with 2.4, the older versions of QGIS will loose
the information about grouping.
If you are interested in studying the new code, there are two new
folders of interest:
- src/core/layertree
- src/gui/layertree
There is basic doxygen documentation for the new core classes, I plan
to add more, add python bindings and unit tests.
Regards
Martin
[1] https://github.com/qgis/QGIS/commit/b2a4c765b4e8a3fa00385a56a358952f46a1957a_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Congratulations for this big cleanup!
I am really glad we (SIGE) could help this project to come true.
On 21 May 2014, at 19:11, Martin Dobias < [hidden email]> wrote:
> Hi everyone
>
> I have just merged the first part of the legend refactoring work to
> master [1]. It does not really bring any new features for the end
> user, the changes are mainly under the hood. Things should ideally
> work as before, if not then probably it is a bug.
>
> There will be second part of the work related mainly around improved
> layer symbology display in legend, more interactive legend and more
> options for customization. At Lutra Consulting we are still looking
> for funders willing to co-fund the work. At this point let me thank
> SIGE and Swiss QGIS User Group for supporting the project.
>
> Please test thoroughly - the legend has received quite a lot of
> features over time, so there could be still some minor features I have
> missed to port to new implementation.
>
> The format of the project file has changed, but there is backward
> compatibility with older projects which should allow seamless
> transition. Once saved with 2.4, the older versions of QGIS will loose
> the information about grouping.
>
> If you are interested in studying the new code, there are two new
> folders of interest:
> - src/core/layertree
> - src/gui/layertree
> There is basic doxygen documentation for the new core classes, I plan
> to add more, add python bindings and unit tests.
>
> Regards
> Martin
>
> [1] https://github.com/qgis/QGIS/commit/b2a4c765b4e8a3fa00385a56a358952f46a1957a> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
A quick test revealed that layer actions added via QgsLegendInterface::addLegendLayerAction() and addLegendLayerActionForLayer() do not show up in the context menu any more.
Should the corresponding members be added to QgsLayerTreeLayer class?
cheers Etienne _______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Hi Martin,
Thanks for your work on this and for the sponsors that supported it!
Couples things I noticed: * There is no longer and indication that a layer is in edit mode, or not, i.e. the edit pencil icon, and its relative states (red or yellow), is gone.
* There is no longer an indication of the active layer, previously the one underlined. This is different than the currently selected layer(s). The underline would persist with no selection, or multiple selections, and would mirror the view's currentItem(), or in maybe now currentIndex(). When iface.activeLayer() is used in console, it should return the identical layer in the legend that is underlined, or otherwise indicated as active.
* Something is funky with the connections between the legend and the Current Edits functionality. After a layer is no layers are editable anymore, the submenu is still active, offering to cancel edits. I added that code, and can investigate more after the feature freeze.
* There is no longer a tool tip when hovering over the layer, showing the layer's source definition. _______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
On Wed, May 21, 2014 at 7:11 PM, Martin Dobias < [hidden email]> wrote:
> Hi everyone
>
> I have just merged the first part of the legend refactoring work to
> master [1]. It does not really bring any new features for the end
> user, the changes are mainly under the hood. Things should ideally
> work as before, if not then probably it is a bug.
Interesting. So your changes will be in Qgis 2.4?
Another question: one thing that was missing to plugins is to set the
layer position in the legend, after I've added it to the map... It's
now possible with your commit?
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Hi Etienne
On Thu, May 22, 2014 at 1:46 AM, Etienne Tourigny
< [hidden email]> wrote:
> A quick test revealed that layer actions added via
> QgsLegendInterface::addLegendLayerAction() and
> addLegendLayerActionForLayer() do not show up in the context menu any more.
I am aware of that, will reintroduce it soon.
Regards
Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Hi Larry
On Thu, May 22, 2014 at 2:39 AM, Larry Shaffer < [hidden email]> wrote:
> Hi Martin,
>
> Thanks for your work on this and for the sponsors that supported it!
>
> Couples things I noticed:
>
> * There is no longer and indication that a layer is in edit mode, or not,
> i.e. the edit pencil icon, and its relative states (red or yellow), is gone.
>
> * There is no longer an indication of the active layer, previously the one
> underlined. This is different than the currently selected layer(s). The
> underline would persist with no selection, or multiple selections, and would
> mirror the view's currentItem(), or in maybe now currentIndex(). When
> iface.activeLayer() is used in console, it should return the identical layer
> in the legend that is underlined, or otherwise indicated as active.
>
> * Something is funky with the connections between the legend and the Current
> Edits functionality. After a layer is no layers are editable anymore, the
> submenu is still active, offering to cancel edits. I added that code, and
> can investigate more after the feature freeze.
>
> * There is no longer a tool tip when hovering over the layer, showing the
> layer's source definition.
Thanks a lot for the feedback. Will address that shortly.
> * When opening one project, QGIS crashed with the following (project never
> loads):
>
> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010
>
> 0 org.qgis.qgis2_core QgsSymbolV2::drawPreviewIcon(QPainter*, QSize) + 42
> (qlist.h:99)
> 1 org.qgis.qgis2_core
> QgsSymbolLayerV2Utils::symbolPreviewPixmap(QgsSymbolV2*, QSize) + 114
> (qgssymbollayerv2utils.cpp:517)
> 2 org.qgis.qgis2_gui
> QgsLayerTreeModel::addSymbologyToVectorLayer(QgsLayerTreeLayer*) + 570
> (qgslayertreemodel.cpp:520)
> 3 org.qgis.qgis2_gui
> QgsLayerTreeModel::addSymbologyToLayer(QgsLayerTreeLayer*) + 88
> (qgslayertreemodel.cpp:480)
> 4 QtCore QMetaObject::activate(QObject*, QMetaObject
> const*, int, void**) + 2141
> 5 org.qgis.qgis2_core
> QgsLayerTreeLayer::registryLayersAdded(QList<QgsMapLayer*>) + 307
> (qgslayertreelayer.cpp:145)
> 6 org.qgis.qgis2_core QgsLayerTreeLayer::qt_static_metacall(QObject*,
> QMetaObject::Call, int, void**) + 172 (qlist.h:731)
Oh, sorry about that. Something must have gone wrong with a vector
layer's symbol. I can't see where the problem could be straight away -
would it be possible for you to send me the project file - or see if
you can provide more information how to replicate the problem?
Regards
Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Hi Luca
On Thu, May 22, 2014 at 1:15 PM, Luca Manganelli < [hidden email]> wrote:
> On Wed, May 21, 2014 at 7:11 PM, Martin Dobias < [hidden email]> wrote:
>> Hi everyone
>>
>> I have just merged the first part of the legend refactoring work to
>> master [1]. It does not really bring any new features for the end
>> user, the changes are mainly under the hood. Things should ideally
>> work as before, if not then probably it is a bug.
>
> Interesting. So your changes will be in Qgis 2.4?
Yes.
> Another question: one thing that was missing to plugins is to set the
> layer position in the legend, after I've added it to the map... It's
> now possible with your commit?
Yes, plugins now have full control of project's layer tree. Simply
obtain the tree (QgsProject::layerTreeRoot()), create a new layer node
(QgsLayerTreeLayer) and add it where it should go
(QgsLayerTreeGroup::insertChildNode()). You will probably want to add
the layer to layer registry without emitting a signal from registry
(QgsMapLayerRegistry::addMapLayer(layer, false)) otherwise it will be
added to the layer tree twice.
Python bindings for the new classes are coming very soon.
Enjoy :-)
Regards
Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Hi Larry
On Fri, May 23, 2014 at 1:30 AM, Larry Shaffer < [hidden email]> wrote:
>>
>> However, I did notice that the new legend is not quite the same as the
>> old. You can now edit the name of the layer directly with a click-hover.
>> Very nice!
>
>
> Hmm. While that feature is nice, it is a little too easy to rename a layer.
> For example, double-clicking the name of a legend layer to bring up
> properties (if set in Options) leaves the layer name in an editable state.
> Upon closing the properties dialog, any keyboard input changes the layer
> name in the legend, because the keyboard focus is still active there.
Does not seem to happen here. I can see that layer name gets into
editing state, but immediately after opening the properties dialog the
editor is closed again.
> Maybe ensure the name is not editable when a double-click is detected? While
> that would fix the noted issue, it doesn't address how often the layer's
> name becomes unintentionally editable during normal legend use.
>
> Any ideas on how to leave the mouse-activated name changing but reduce
> unintentional editing?
I guess we can just go back to the original behaviour without the
"SelectedClicked" edit trigger. Probably not worth some additional
hacks to keep this feature alive. And then there is still F2 for quick
renaming...
Regards
Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Hi Martin,
Le 21/05/2014 19:11, Martin Dobias a écrit :
> Hi everyone
>
> I have just merged the first part of the legend refactoring work to
> master [1]. It does not really bring any new features for the end
> user, the changes are mainly under the hood. Things should ideally
> work as before, if not then probably it is a bug.
>
Thanks for all the great work.
When adding a new layer, the behaviour used to be that the new layer was
placed on top of the active layer. It is not the case anymore if I am
correct.
When passing a list of layers in a certain order to
QgsMapCanvas::setLayerSet(), the obtained order seems random (from
Python). Is it wanted ? (not sure if it was already the case before your
changes)
Is there a way to modify the order of layers in the legend (and in the
rendering) via the Python API ?
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Hi Hugo
On Mon, Jun 2, 2014 at 10:13 PM, Hugo Mercier < [hidden email]> wrote:
> Hi Martin,
>
> Le 21/05/2014 19:11, Martin Dobias a écrit :
>> Hi everyone
>>
>> I have just merged the first part of the legend refactoring work to
>> master [1]. It does not really bring any new features for the end
>> user, the changes are mainly under the hood. Things should ideally
>> work as before, if not then probably it is a bug.
>>
>
> Thanks for all the great work.
>
> When adding a new layer, the behaviour used to be that the new layer was
> placed on top of the active layer. It is not the case anymore if I am
> correct.
Works for me exactly as expected - new layer is placed on top of the
active layer.
> When passing a list of layers in a certain order to
> QgsMapCanvas::setLayerSet(), the obtained order seems random (from
> Python). Is it wanted ? (not sure if it was already the case before your
> changes)
I am not sure if I understand what you mean.... order obtained from
where? from map canvas?
> Is there a way to modify the order of layers in the legend (and in the
> rendering) via the Python API ?
Not yet, I am about to add python bindings very soon (tomorrow probably).
Regards
Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Le 02/06/2014 17:36, Martin Dobias a écrit :
> Hi Hugo
>
> On Mon, Jun 2, 2014 at 10:13 PM, Hugo Mercier < [hidden email]> wrote:
>> Hi Martin,
>>
>> Le 21/05/2014 19:11, Martin Dobias a écrit :
>>> Hi everyone
>>>
>>> I have just merged the first part of the legend refactoring work to
>>> master [1]. It does not really bring any new features for the end
>>> user, the changes are mainly under the hood. Things should ideally
>>> work as before, if not then probably it is a bug.
>>>
>>
>> Thanks for all the great work.
>>
>> When adding a new layer, the behaviour used to be that the new layer was
>> placed on top of the active layer. It is not the case anymore if I am
>> correct.
>
> Works for me exactly as expected - new layer is placed on top of the
> active layer.
>
After some more tests, it seems to happen when a layer is first removed.
To reproduce :
* start from a blank project,
* add a new layer,
* add another layer,
* remove the newly added,
* add another layer => it will be placed at the bottom, and if you do it
again, on top, and then at the bottom, etc.
>
>> When passing a list of layers in a certain order to
>> QgsMapCanvas::setLayerSet(), the obtained order seems random (from
>> Python). Is it wanted ? (not sure if it was already the case before your
>> changes)
>
> I am not sure if I understand what you mean.... order obtained from
> where? from map canvas?
Say, from a Python plugin, if you want to reorder layers rendered on the
map canvas. But what I observed might be linked to the previous issue.
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
On Tue, Jun 3, 2014 at 7:42 PM, Hugo Mercier < [hidden email]> wrote:
> Le 02/06/2014 17:36, Martin Dobias a écrit :
>> Hi Hugo
>>
>> On Mon, Jun 2, 2014 at 10:13 PM, Hugo Mercier < [hidden email]> wrote:
>>> Hi Martin,
>>>
>>> Le 21/05/2014 19:11, Martin Dobias a écrit :
>>>> Hi everyone
>>>>
>>>> I have just merged the first part of the legend refactoring work to
>>>> master [1]. It does not really bring any new features for the end
>>>> user, the changes are mainly under the hood. Things should ideally
>>>> work as before, if not then probably it is a bug.
>>>>
>>>
>>> Thanks for all the great work.
>>>
>>> When adding a new layer, the behaviour used to be that the new layer was
>>> placed on top of the active layer. It is not the case anymore if I am
>>> correct.
>>
>> Works for me exactly as expected - new layer is placed on top of the
>> active layer.
>>
>
> After some more tests, it seems to happen when a layer is first removed.
> To reproduce :
> * start from a blank project,
> * add a new layer,
> * add another layer,
> * remove the newly added,
> * add another layer => it will be placed at the bottom, and if you do it
> again, on top, and then at the bottom, etc.
Thanks for the test case. Should be fixed now, please check again with
latest master.
>>> When passing a list of layers in a certain order to
>>> QgsMapCanvas::setLayerSet(), the obtained order seems random (from
>>> Python). Is it wanted ? (not sure if it was already the case before your
>>> changes)
>>
>> I am not sure if I understand what you mean.... order obtained from
>> where? from map canvas?
>
> Say, from a Python plugin, if you want to reorder layers rendered on the
> map canvas. But what I observed might be linked to the previous issue.
You can reorder layers in map canvas by simply reordering the entries
in the layer tree - the same way as done with drag'n'drop: 1. add a
new node(s), 2. remove old node(s). Simply get the layer tree from
project (QgsProject.instance().layerTreeRoot()) and then just call the
root group's methods to add/remove nodes.
Alternatively one could use the map canvas bridge class and set a
customized layer order in case the layer order in canvas should not be
the same as in the tree. The bridge class is currently not exposed
from QgisApp, though no problem to add it.
Regards
Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
|
|
Hi Tim
On Tue, Jun 3, 2014 at 7:14 AM, Tim Sutton < [hidden email]> wrote:
>
> Ah on this topic I dont know if we mentioned it in Vienna when you were
> gathering requirements, but one thing I *often* get asked by users is why
> when adding new layers (multiple at once) QGIS does not add them in 'natural
> z-order' with polygons below then lines in the middle, then points above. Is
> this something you could do? I believe sorting should only apply to the
> added layers (so adding the sorted layer above the current layer rather than
> above the last layer of their geometry type). Though no doubt somebody will
> think just the opposite....:-)
Hmmm this feature should be actually quite easy to add. I'm just
wondering where to put layers without geometry (to the top?) and
raster layers (to the bottom?)
Regards
Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
|
123
|
Locked
