<div dir="ltr">Hi<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 10:37 PM, Benedict Holland <span dir="ltr"><<a href="mailto:benedict.m.holland@gmail.com" target="_blank">benedict.m.holland@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Tim,<div><br></div><div>I think once I start working on this it will become quite apparent if I can make 1, if I can't make 1 but don't break anything I make 2, or I can't make 1, break a mess of code and so result in 3. Currently I see that the TOC and Legend are tied directly to a "master" project, though it is currently not called that. I think it would make more sense to push a Legend onto the QgsSubproject and I think I have a great use case in mind. ArcGIS currently allows multiple maps to be displayed in their Layout View. If we mimic this on the Composer side then we would have say, 6 maps of Africa, displaying different wildlife and oil reserves. This example is pulled directly out of ArcGIS desktop v10.0. The Legend would have to be unique for each map but there would also have to be a global Legend generated from the Legends and allow the user to select which one they want displayed. The QgsSubproject legend would be tied to each of the maps in the Composer and each map would be able to generate their own but the canvas would be able to generate a Legend from each of the maps that are currently active in the Composer. </div>
<div><br></div><div>We might even be able to get this for relatively little work depending on how the legend is generated. </div><div><br></div><div>Actually I do have a question regarding a lot of this. I have been diving into the code and I see that many objects are managed using XML. Is there a reason why XML is so heavily used and should I be trying to think in terms of exporting objects and manipulating objects with XML or via private class objects. I have learned to be very careful of using XML as it is very difficult to debug and the code is not intuitive. For example, adding a layer to a project currently directly edits XML somehow. Adding an object to the Legend directly edits the XML of the Legend, though the legend also uses a dictionary like object. Basically, the usefulness I have found for XML is to load objects from a saved state, magically create variables from text (though I am still unsure how this works and I worked on a project which did this for over a year), and pass objects around the internet. It is not that I dislike XML, but I dislike using XML. </div>
</blockquote><div><br></div><div><br></div><div style>Marco and Jürgen can speak better about the architecture side of things, but AFIAK we only use XML to save and load state, not to drive behaviour or pass objects around internally. Other than the fact that it is probably a massive undertaking, there is no reason why we couldn't use e.g. sqlite to store project state in a simple database rather - in fact some have already mulled the idea around as it would allow us to e.g. store memory layers efficiently with the project.</div>
<div style><br></div><div style>Regards</div><div style><br></div><div style>Tim</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>Thanks,</div><div>~Ben</div><div class="HOEnZb"><div class="h5"><div><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 3:07 PM, Tim Sutton <span dir="ltr"><<a href="mailto:tim@linfiniti.com" target="_blank">tim@linfiniti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi<div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>
On Wed, Jan 9, 2013 at 9:47 PM, Benedict Holland <span dir="ltr"><<a href="mailto:benedict.m.holland@gmail.com" target="_blank">benedict.m.holland@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><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><br>
<br>
<br>
On <a href="tel:09.01.2013%2001" value="+27901201301" target="_blank">09.01.2013 01</a>: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><font color="#888888">
</font></span></pre><span><font color="#888888">
</font></span></blockquote><span><font color="#888888">
<br></font></span></div></blockquote></div></div></div></div></blockquote><div><br></div></div></div><div>Ben this would be a really great addition! Just in terms of timings, we are waiting for a big change to come into the code base from Martin to support threaded rendering and then we will be gearing up for the release of 2.0. It would be worth polling him to see if your plans will be impacted by his impending changes. Also if your changes will result in substantive API changes bear in mind that once we release 2.0 we will need new work coming into QGIS to maintain API compatibility until such time as we hit 3.0. So that means basically one of the following scenarios:</div>
<div><br></div><div>1) your changes are implemented and merged by the 2.0 major release freeze (date as yet to be determined but probably one or two months time)</div><div>2) your changes are implemented as part of an 2.x minor release and maintain backwards api compatibility.</div>
<div>3) your changes are merged as part of a future 3.0 release (breaking api again)</div><div><br></div><div>Out of curiosity, how did you envisage the legends / TOC to work in the ui - would legend be an embedded part of the dataframe or would there be only a single legend / TOC whose contents update depending on which canvas is active?</div>
<div><br></div><div>Regards</div><div><br></div><div>Tim</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div>
<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span><font color="#888888">
<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" 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>
</div></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></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Tim Sutton - QGIS Project Steering Committee Member (Release Manager)<br>==============================================<br>
Visit <a href="http://linfiniti.com" target="_blank">http://linfiniti.com</a> to find out about:<br>
* QGIS programming services<br> * Mapserver and PostGIS based hosting plans<br> * FOSS Consulting Services<br>Skype: timlinux Irc: timlinux on #qgis at <a href="http://freenode.net" target="_blank">freenode.net</a><br>==============================================
</font></span></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tim Sutton - QGIS Project Steering Committee Member (Release Manager)<br>==============================================<br>Visit <a href="http://linfiniti.com">http://linfiniti.com</a> to find out about:<br>
* QGIS programming services<br> * Mapserver and PostGIS based hosting plans<br> * FOSS Consulting Services<br>Skype: timlinux Irc: timlinux on #qgis at <a href="http://freenode.net">freenode.net</a><br>==============================================
</div></div>