[Qgis-developer] General questions & multiple map canvases

[humarco]

Hi Martin and Tim,

Just some general thoughts from my side:

I can see two different possible directions of how multiple canvas could work:

1. Different views to the same project. The canvases use exaclty the same 
layer set, symbology, legend (not necessarily the same CRS). Only the view 
extent is different.

2. Different views to different projects. Each canvas has a different layer 
set, symbology, CRS, legend.

I can imagine uses for both. Personally i would prefer the first one. The user 
could have 2. by opening multiple qgis windows. And the number of clicks 
would be the same (clicking on qgis icon on desktop instead on 'add canvas'). 
To have 1. would be more inconvenient with two qgis instances(save current 
project, open new qgis, open the same project). Additionally, if the project 
changes in one qgis instance, the project has to be saved again and reopened 
in the second qgis instance. 
 

In case the general consensus is 2., wouldn't it be simpler to have 
independent instances of legend, maplayers and even layer registries for each 
canvas? As the data providers read from disk, there wouldn't be much storage 
overhead compared to sharing maplayers. And i think it would make it 
conceptually much simpler because most of the existing classes wouldn't need 
to be changed.


Regards,
Marco


Am Samstag 06 Mai 2006 00:44 schrieb Tim Sutton:
> Hi Martin
>
> On 5/5/06, Martin Dobias <wonder.sk at gmail.com> wrote:
> > Hi all,
> >
> > I'd like to discuss here the concept of multiple map canvas support.
> > The reason of starting the discussion is that I think often it's not
> > very clear (at least for me) what part of QGIS application should be
> > responsible of what task.
>
> Right we need to iron these things out nicely still....
>
> > Parts of QGIS I'm currently talking about
> > are map layer registry, project, map canvas and legend. Their
> > cooperation affects also how they should be handled in other
> > applications. The questions for which I don't have clear answers
> > include:
> >
> > - should be every new layer added to map layer registry?
>
> Yes but we should change maplayer so that it only stores the 'from'
> part of the SRS so that a layer can be used in multiple canvases which
> have different canvas SRS.
>
> I do wonder if we would not be better having a formalised
> QgsMapLayerCollection with iterator capability (and doing away with
> the map layer registry singleton). The QgsMapLayerCollection would
> store all the handles to map layers for a given canvas. Layers could
> be shared among canvases by virtue of being pointers. With reference
> counting the layer can be destroyed when last ref to it is lost.
> However from the UI point of view the user would need to understand
> that layers shared between canvases are linked and that changes to
> symbology in on canvas will affect all its representations in other
> canvaes.
>
> > - should be every layer added to registry added also to the legend in
> > gui application?
>
> I would like to see a situation where we can do:
>
> QgsLegend->setLayersCollection(QgsMapCanvas->layersCollection())
>
> Where the QgsMapCanvas->layersCollection() would return a pointer to
> the QgsMapLayersCollection so that the legend would automatically sync
> with canvas and verca vica. It certainly would be useful to be able to
> hide individual layers form the legend in bespoke apps (e.g. where you
> wish to have an immuteable backdrop layer). This could probably be
> best achieved with a QgsMapLayer->hideFromLegend(true) type of call.
>
> > - similarly, when a layer is removed from legend, should it be also
> > removed from registry and deleted?
>
> We should ref count it. But see comments above, I think moving to a
> MapLayersCollection may be a better  bet.
>
> > It's easy to answer these questions when we consider only single
> > legend and map canvas. However with more map canvases, it depends of
> > what do we expect from multiple canvas support:
> > - allow different projection for every map canvas or the same for all
> > canvases in project?
>
> Each canvas should be able to specify its own canvas SRS
>
> > - the same layer properties (e.g. symbology, labeling) in every canvas
> > or allow different ones?
>
> I think initially we should share symbology across shared instances of
> a layer. We need to asess how much overhead having duplicates of the
> same data source as separate QgsMapLayer objects with different
> symbologies versus splitting symbology furter away from map layer so
> that multiple symbologies can be assigend to the same qgsmaplayer
> instance.
>
> > - how should plugins work with canvas? E.g. enabling scale bar plugin
> > will show scale bar in all canvases or in active canvas only?
>
> Good point. They should be assigned on a per canvas basis I think. We
> should adapt the plugin api to cater for this and in most cases the
> plugin writer himself should dictate whether the plugins scope is
> global or to a specific canvas instance.
>
> > - should one legend control all map canvases or let's have one legend
> > for every canvas?
>
> Each canvas should have its own legend instance. We should swap out th
> elegend control with which ever canvase is currently in focus.
>
> > - how to present it to the users? By this I mean whether do you plan
> > to have just "Add canvas" and "Remove canvas" buttons or something
> > more complicated with more features?
>
> Yes simple add and remove canvas buttons, and this must be exposed to
> plugin api. Also plugin api should be able to addTab, removeTab where
> the tab can be used by plugin writer for other non canvas stuff e.g.
> displaying a form.
>
> > Answers to these questions will help me to prepare API correctly for
> > 3rd party applications.
>
> Go Martin Go! :-) These are my thoughts anyway, other people may have
> different ideas / better ideas.
>
> Regards
>
> Tim
>
> > Martin
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.qgis.org
> > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>
> --
> Tim Sutton
>
> Visit http://qgis.org for a great Open Source GIS
> Skype: timlinux
> MSN: tim_bdworld at msn.com
> Yahoo: tim_bdworld at yahoo.com
> Jabber: timlinux
> Irc: timlinux on #qgis at freenode.net
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.qgis.org
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer