<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Benedict<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>
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<br>
<br>
On 09.01.2013 20:47, Benedict Holland wrote:<br>
</div>
<blockquote
cite="mid:CAD+mzowns8cEfCGpJgyrDcjU6DNi7KFr+Ma8diO41azut05V1w@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<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 moz-do-not-send="true"
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 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 moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a>
<a moz-do-not-send="true" href="http://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-psc</a><span class="HOEnZb">
</span></pre>
<span class="HOEnZb"> </span></blockquote>
<span class="HOEnZb"> <br>
<br>
<pre cols="72">--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
<a moz-do-not-send="true" href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">marco.hugentobler@sourcepole.ch</a> <a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Qgis-psc@lists.osgeo.org">Qgis-psc@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
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 class="moz-signature" cols="72">--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
<a class="moz-txt-link-abbreviated" href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a class="moz-txt-link-freetext" href="http://www.sourcepole.ch">http://www.sourcepole.ch</a>
Technical Advisor QGIS Project Steering Committee </pre>
</body>
</html>