Marco, <div><br></div><div>I like this suggestion. This can also be written in a way with a data frame like object in mind and I can add linking layer extents to layers which can be moved later to the parent object. Having a list of layers which are displayed is a small UI change and would default to behave like it does now. As an introductory project do you think this would be doable? This would also allow time to solidify the data frames concept for the 3.0 push or get in most api changes into 3.0. </div>
<div><br></div><div>I will write up an RFC and post it shortly and update the RFC for data frames to reflect the most recent conversations. </div><div><br></div><div>~Ben <br><br><div class="gmail_quote">On Thu, Jan 10, 2013 at 10:02 AM, Marco Hugentobler <span dir="ltr"><<a href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">marco.hugentobler@sourcepole.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hi Benedict<div class="im"><br>
<br>
>The huge downside to this is that a change like this could
break a lot more code than a smaller change like just having the
data frame be a simple collection of layers. I would be impacting
quite a lot >of code with these changes. I am not familiar
enough with how a canvas is actually displayed yet or how the
composer displays objects to know if my changes would force a lot
of changes. I don't >particularly want to be rewriting most of
QgsCore as a first project, alone. <br>
<br></div>
Yes, I agree. Changing the logic between QgsProject and
QgsMapLayer has a lot of side effects. In my opinion it is not an
ideal first project.<br>
<br>
If you are mainly interested in having multiple maps in composer,
you could as well modify QgsComposerMap / -Widget with a
possibility to select the layers you want in the composer map.
Like that, you could embed groups / layers from other projects
into the map canvas and, in print composer, create maps with
different layer sets.<br>
I know this does not replace the need of having multiple views /
datasets some day, but it is an approach without modifying a lot
of core classes.<br>
<br>
Regards,<br>
Marco<div><div class="h5"><br>
<br>
On 09.01.2013 20:47, Benedict Holland wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div>Hi all,</div>
<div><br>
</div>
So this then asks a fairly fundamental question: what exactly
would I be developing? The data frame could handle rendering but I
suppose that it would just be a question of if want the QgsProject
to handle it or push it down a level. I like the idea of data
frames handling it the more I think about it however. This would
actually closely mimic what the QgsProject does currently. If we
go down this route, would it be fair to call it a subproject ie
QgsSubproject? I think that this would fully encapsulate the idea
that I am creating a way to generate projects which would have
multiple layers, link to different subprojects, have a canvas,
legend, display properties, interactions with the Composer, etc. I
like this name also because it has a direct link to QgsProject in
that a QgsProject is made up of QgsSubproject objects. This is a
logical grouping which makes more sense than data frames.
<div>
<br>
</div>
<div>The huge downside to this is that a change like this could
break a lot more code than a smaller change like just having the
data frame be a simple collection of layers. I would be
impacting quite a lot of code with these changes. I am not
familiar enough with how a canvas is actually displayed yet or
how the composer displays objects to know if my changes would
force a lot of changes. I don't particularly want to be
rewriting most of QgsCore as a first project, alone. </div>
<div><br>
</div>
<div>Also a huge problem that I see with this project is that I
don't have a good way of coding in the way that is specified in
the CODING doc where I would have something like load()
loadNew() because I am fundamentally changing what entire
classes do and how they relate to each other. If no one else is
working in this area then I can basically do what needs to be
done but merging code when object relationships change is very
difficult and I have not seen a great way to manage that
process. If there are no complaints then I will edit the RFC to
reflect the QgsSubproject principal and send out an updated RFC
to the list serve. </div>
<div><br>
</div>
<div>Thanks,</div>
<div>~Ben</div>
<div><br>
<div class="gmail_quote">On Wed, Jan 9, 2013 at 11:15 AM, Marco
Hugentobler <span dir="ltr"><<a href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">marco.hugentobler@sourcepole.ch</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div>
<div>Hi Benedict<br>
<br>
It is a good direction to go towards multiple views /
dataframes. This is a frequent feature-wish and it is
good to know someone is working on it.<br>
<br>
The RFC is centered around data frames as layer
collections, but I think it would involve more than just
QgsProject and QgsMapLayer. E.g. every frame could have
it's own canvas / layer set / output crs (maybe even
legend, overview map). Therefore, the term data frame
may need to be changed.<br>
<br>
Once you are working on QgsProject, don't forget that
layers and whole groups can be embedded from other
projects / frames.<br>
<br>
<br>
Regards,<br>
Marco
<div>
<div><br>
<br>
<br>
On 09.01.2013 01:04, Benedict Holland wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>Hi All,
<div><br>
</div>
<div>I don't know if I can actually call this
project data frames as I don't know if that is
TMed by ESRI but regardless the concept is the
same. The RFC is located here:</div>
<div><br>
</div>
<div> <a href="http://hub.qgis.org/wiki/quantum-gis/Data_Frames" target="_blank">http://hub.qgis.org/wiki/quantum-gis/Data_Frames</a></div>
<div><br>
</div>
<div>This would be a substantial change to the
current architecture of QgsProjects and the
relationship between QgsProjects and QgsMapLayers.
I have been a professional developer for about 6
years or so and have worked on projects much
larger than this but not in c++ for quite some
time. I do though use best practices including
unit tests and documentation as part of a standard
development procedure and I applaud
your requirements that these be included in this
feature. While I do expect this will change
the architecture I do not expect much will break
unless previous releases cannot load a project
file from a future release but honestly, there is
little I or anyone else can do about that now
except tell people to upgrade. If there isn't
currently a way to handle future releases then I
will also create a method for doing that and file
it under the same RFC linked above. </div>
<div><br>
</div>
<div>Let me know what you can think. I am eager to
get working on this as it would make
life substantialy easier for me in the direct
future. </div>
<div>~Ben Holland</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Qgis-psc mailing list
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-psc</a><span>
</span></pre>
<span> </span></blockquote>
<span> <br>
<br>
<pre cols="72">--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
<a href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">marco.hugentobler@sourcepole.ch</a> <a href="http://www.sourcepole.ch" target="_blank">http://www.sourcepole.ch</a>
Technical Advisor QGIS Project Steering Committee </pre>
</span></div>
<br>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre cols="72">--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
<a href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">marco.hugentobler@sourcepole.ch</a> <a href="http://www.sourcepole.ch" target="_blank">http://www.sourcepole.ch</a>
Technical Advisor QGIS Project Steering Committee </pre>
</div></div></div>
</blockquote></div><br></div>