<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" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<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 class="h5"><br>
<br>
<br>
On 09.01.2013 01:04, Benedict Holland wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">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 class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<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>
</font></span></div>
<br>_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org">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>