<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>
>As an introductory project do you think this would be doable?<br>
<br>
Yes, I think this would provide a nice functionality and it is a
good introductory project while the frame/subproject/view
discussion is going on.<br>
<br>
Regards,<br>
Marco<br>
<br>
On 10.01.2013 17:48, Benedict Holland wrote:<br>
</div>
<blockquote
cite="mid:CAD+mzowyZfkwH+VbcwcYwXrvWL8X=iexA6V6YNeh4ygR25N-oA@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
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 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
<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
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><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 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>
</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 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"
target="_blank">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 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>
</div>
</div>
</div>
</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>