[Qgis-developer] General questions & multiple map canvases

[Martin Dobias]

On 5/7/06, humarco <marco.hugentobler at karto.baug.ethz.ch> wrote:
> 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.

Hi,

I see one more possible direction which is the mix of the two you mention:

3. different views to the same project, but canvas can have different
layer set, symbology, CRS and 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.

I've posted a concept of such solution with more layer registries for
each canvas as we dicussed it on IRC...

I think it would be wise to organize a poll in user community (on web
or on mailing list) what handling of multiple map canvas they like at
most and implement it based on their opinions.


Martin

>
>
> 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
>