Hi On Fri, Apr 19, 2013 at 10:45 PM, Martin Dobias <wonder...@gmail.com> wrote: > Hi Matthias > > On Fri, Apr 19, 2013 at 4:07 PM, Matthias Kuhn <matthias.k...@gmx.ch> wrote: >> The QgsMapLayerRegistry::removeMapLayers allows to specify a parameter, >> which will suppress emitting signals (altough it seems that this is not >> even properly working [1]). >> >> This parameter can lead to strange behavior, where some parts of the >> software might not realize, that a layer has been removed and keep >> references to no longer available objects. > > I completely agree with you - it is a bad practice to pass a parameter > whether to emit signal or not - it is typically something that leads > to wrong design. > > >> So my questions are: >> * Does somebody know why removeMapLayer(s) accepts this parameter? >> * Do you see any negative effect of removing these or any upside in >> keeping these? > > I remember we have added that to support georeferencer. The workflow > with layers in QGIS is currently:
Ah ok I thought that was me :-) > 1. create Qgs[Vector/Raster]Layer instance > 2. add the layer to map registry > 3. map registry emits signal, caught by legend widget > 4. legend widget adds the layer to the list of layers and updates the > list of layers in canvas > Georeferencer comes with its own map canvas and its own set of layers. > When we add a layer that should be georeferenced, we do not want it to > appear also on main canvas - that's where the 'emit signal' parameter > comes handy. Setting it to false will avoid loading the layer in the > main window. > > There are surely more ways how to fix the problem, but probably all of > them involve slight redesign of how the components are interconnected. > Maybe we do not need a map layer registry. Or maybe we could have > several map layer registries (instead of just having singleton), one > for each canvas in the application. Or maybe we need something more > general than just a list of layers: e.g. right now the ordering is > defined by legend widget... for a proper logic/gui separation we > should keep the layers + ordering + grouping in a data structure (and > only let legend widget serve as its view and controller). > > I am not sure how feasible is to do something about it now, but in any > case I would warmly welcome another shift of API freeze, the amount of > things we need to fix in API is quite high (e.g. in my pipeline: > symbology-ng "V2" renaming, feature iterators + requests API fixes, > QgsVectorLayer API updates, QgsExpression API fixes, sip API 2 and > probably more). Yes agreed I will propose another shift to the end of April (feature freeze remaining in effect). Regards Tim > > Cheers > Martin > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) ============================================== Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net ============================================== _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
