[Qgis-psc] RFC for Data Frames

Wed Jan 9 12:07:03 PST 2013

Hi

On Wed, Jan 9, 2013 at 9:47 PM, Benedict Holland <
benedict.m.holland at gmail.com> 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> 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 listQgis-psc at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>>
>>
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:

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)
2) your changes are implemented as part of an 2.x minor release and
maintain backwards api compatibility.
3) your changes are merged as part of a future 3.0 release (breaking api
again)

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?

Regards

Tim

>
>> --
>> Dr. Marco Hugentobler
>> Sourcepole -  Linux & Open Source Solutions
>> Weberstrasse 5, CH-8004 Zürich, Switzerlandmarco.hugentobler at sourcepole.ch http://www.sourcepole.ch
>> Technical Advisor QGIS Project Steering Committee
>>
>>
>> _______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>

-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Visit http://linfiniti.com to find out about:
 * QGIS programming services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.net
==============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20130109/1b0436d2/attachment.html>