[Qgis-psc] RFC for Data Frames
Marco Hugentobler
marco.hugentobler at sourcepole.ch
Thu Jan 10 07:02:38 PST 2013
Hi Benedict
>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.
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.
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.
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.
Regards,
Marco
On 09.01.2013 20:47, Benedict Holland wrote:
> Hi all,
>
> 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.
>
> 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.
>
> 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.
>
> Thanks,
> ~Ben
>
> On Wed, Jan 9, 2013 at 11:15 AM, Marco Hugentobler
> <marco.hugentobler at sourcepole.ch
> <mailto:marco.hugentobler at sourcepole.ch>> wrote:
>
> Hi Benedict
>
> 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.
>
> 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.
>
> Once you are working on QgsProject, don't forget that layers and
> whole groups can be embedded from other projects / frames.
>
>
> Regards,
> Marco
>
>
>
> On 09.01.2013 01:04, Benedict Holland wrote:
>> Hi All,
>>
>> 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:
>>
>> http://hub.qgis.org/wiki/quantum-gis/Data_Frames
>>
>> 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.
>>
>> 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.
>> ~Ben Holland
>>
>>
>> _______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org <mailto:Qgis-psc at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole - Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, Switzerland
> marco.hugentobler at sourcepole.ch <mailto:marco.hugentobler at sourcepole.ch> http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org <mailto:Qgis-psc at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20130110/acdbe5a4/attachment.html>
More information about the Qgis-psc
mailing list