[Qgis-psc] RFC for Data Frames
Marco Hugentobler
marco.hugentobler at sourcepole.ch
Fri Jan 11 01:20:17 PST 2013
Hi Benedict
>As an introductory project do you think this would be doable?
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.
Regards,
Marco
On 10.01.2013 17:48, Benedict Holland wrote:
> Marco,
>
> 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.
>
> I will write up an RFC and post it shortly and update the RFC for data
> frames to reflect the most recent conversations.
>
> ~Ben
>
> On Thu, Jan 10, 2013 at 10:02 AM, Marco Hugentobler
> <marco.hugentobler at sourcepole.ch
> <mailto:marco.hugentobler at sourcepole.ch>> wrote:
>
> 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 <mailto:marco.hugentobler at sourcepole.ch> http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
>
--
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/20130111/45f67585/attachment.html>
More information about the Qgis-psc
mailing list