Re: [Qgis-developer] Visualisation of relations

[kimaidou]

Hi all,

Speaking about child tables, I would rather have them presented as table
and not forms by default (or have an option to decide this for QGIS
installation). Usually you only want to see the list of children for each
relation, which is more compact, and show very fast if there is zero or any
children.

Michaël

2016-10-31 14:58 GMT+01:00 Patrick Valsecchi <
patrick.valsec...@camptocamp.com>:

> OK, I've created a PR for auto-detecting N-1 relations and pick the
> RelationReference widget for the foreign key fields.
> https://github.com/qgis/QGIS/pull/3699
>
> For the deep relations UX problem, I really don't know. Do we have UX
> experts among the QGIS devs?
>
> Thanks.
>
> On Mon, Oct 31, 2016 at 1:51 PM, Matthias Kuhn 
> wrote:
>
>> On 10/31/2016 01:26 PM, Patrick Valsecchi wrote:
>> > Matthias,
>> >
>> > Hummm... I don't know about the tabs. Initially I was thinking it would
>> > be a good idea, then I tried to imagine how it would look like for
>> > linked layers within linked layers. We would have two choices:
>> >
>> >   * Have QTabWidget within QTabWidget: tabs within tabs is a UX
>> nightmare
>> >   * Switch to the current way of representing relations for
>> > sub-relations: that would lead to user confusion because we have two
>> > ways of representing relations.
>> >
>> > What do you think? To me, tabs is not a good idea.
>>
>> I think the (current) groupbox within groupbox approach suffers from the
>> same UX defficiencies. At least I get confused regularly.
>>
>> Maybe
>>
>> * toplevel tabs
>> * first sublevel groupbox
>> * second sublevel ...
>>   groupbox again?
>>   skip?
>>   button to open in separate window?
>>
>> Matthias
>>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Patrick Valsecchi]

OK, I've created a PR for auto-detecting N-1 relations and pick the
RelationReference widget for the foreign key fields.
https://github.com/qgis/QGIS/pull/3699

For the deep relations UX problem, I really don't know. Do we have UX
experts among the QGIS devs?

Thanks.

On Mon, Oct 31, 2016 at 1:51 PM, Matthias Kuhn  wrote:

> On 10/31/2016 01:26 PM, Patrick Valsecchi wrote:
> > Matthias,
> >
> > Hummm... I don't know about the tabs. Initially I was thinking it would
> > be a good idea, then I tried to imagine how it would look like for
> > linked layers within linked layers. We would have two choices:
> >
> >   * Have QTabWidget within QTabWidget: tabs within tabs is a UX nightmare
> >   * Switch to the current way of representing relations for
> > sub-relations: that would lead to user confusion because we have two
> > ways of representing relations.
> >
> > What do you think? To me, tabs is not a good idea.
>
> I think the (current) groupbox within groupbox approach suffers from the
> same UX defficiencies. At least I get confused regularly.
>
> Maybe
>
> * toplevel tabs
> * first sublevel groupbox
> * second sublevel ...
>   groupbox again?
>   skip?
>   button to open in separate window?
>
> Matthias
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Matthias Kuhn]

On 10/31/2016 01:26 PM, Patrick Valsecchi wrote:
> Matthias,
> 
> Hummm... I don't know about the tabs. Initially I was thinking it would
> be a good idea, then I tried to imagine how it would look like for
> linked layers within linked layers. We would have two choices:
> 
>   * Have QTabWidget within QTabWidget: tabs within tabs is a UX nightmare
>   * Switch to the current way of representing relations for
> sub-relations: that would lead to user confusion because we have two
> ways of representing relations.
> 
> What do you think? To me, tabs is not a good idea.

I think the (current) groupbox within groupbox approach suffers from the
same UX defficiencies. At least I get confused regularly.

Maybe

* toplevel tabs
* first sublevel groupbox
* second sublevel ...
  groupbox again?
  skip?
  button to open in separate window?

Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Patrick Valsecchi]

Matthias,

Hummm... I don't know about the tabs. Initially I was thinking it would be
a good idea, then I tried to imagine how it would look like for linked
layers within linked layers. We would have two choices:

   - Have QTabWidget within QTabWidget: tabs within tabs is a UX nightmare
   - Switch to the current way of representing relations for sub-relations:
   that would lead to user confusion because we have two ways of representing
   relations.

What do you think? To me, tabs is not a good idea.

Thanks

On Mon, Oct 31, 2016 at 10:06 AM, Matthias Kuhn  wrote:

> Hi Patrick,
>
> for the side that contains the foreign key, there is the "relation
> reference" widget which has a configuration option "show embedded form"
> (I haven't used it in years and a quick check on it didn't work, so
> maybe it needs fixing).
>
> Agreed, collapsed by default makes sense for huge models. For small ones
> it's a bit strange though. Another approach would be to put them on
> separate tabs by default, I think that could look quite nice also. What
> do you think?
>
> Regards
> Matthias
>
> On 10/31/2016 09:54 AM, Patrick Valsecchi wrote:
> > Hi Matthias,
> >
> > My screenshot shows only 1:N links. N:1 links are not supported. By N:1,
> > I mean the relations from the side that contains the foreign key. If I
> > open the form for the "appart" layer, it doesn't show the linked
> "maison".
> >
> > Yes, the collapsed state is remembered, but the default should be
> > collapsed. If the default is to open everything, the GUI is going to
> > explode if we have hundreds of linked tables.
> >
> > Thanks and CU.
> >
> > On Sun, Oct 16, 2016 at 8:57 AM, Matthias Kuhn  > > wrote:
> >
> > Hi Patrick,
> >
> > Making forms and relations more usable is always welcome.
> >
> > What exactly are the problems you have with the current solution?
> > I see that you mentioned the lack of the N:1 side which is available
> > including add feature, add link, remove feature, remove link pretty
> much
> > the way you describe it. On [1] there is some explanation I wrote on
> the
> > first implementation.
> >
> > I think you should have found that since it's shown on the screenshot
> > which is attached to your mail.
> >
> > Also lazy loading (load when first visible) was introduced once for
> > performance reasons and the collapsed state of the group boxes
> > containing the QgsRelationEditor widget is remembered.
> >
> > So I think that functionality-wise, most of it should be there
> already.
> > With a lot of air left for improvement on the usability side.
> >
> > Cheers
> > Matthias
> >
> > [1] http://blog.vitu.ch/10112013-1201/qgis-relations
> > 
> >
> >
> > On 10/07/2016 09:27 AM, Patrick Valsecchi wrote:
> > > Hi,
> > >
> > > I'm tasked with making QGIS a bit more usable with complex database
> > > schemas having a lot of relations (up to hundreds of linked
> tables). The
> > > INSPIRE people were a bit too inspired when creating their data
> schemas
> > > and now we have to try to make QGIS able to cope with that.
> > >
> > > My concerns with the current situation (as of QGIS master) are:
> > >
> > >   * We can specify the relations between the layers at the project
> > level
> > > (it's now easier with the auto-discover feature for PostGIS and
> > > Spatialite). But those are only showing in the
> QgsAttributeForm for
> > > the 1-N side (the side that doesn't have the foreign key). Why
> not
> > > on the N-1 side?
> > >   * For showing the N-1 side in the QgsAttributeForm, one can
> define a
> > > Join in the layer's properties, but I don't see the point of
> having
> > > to define it here as well when we have already the relations
> info at
> > > the project level. I see a use for special joins, but for
> relations,
> > > I don't see why we have to define it twice. And the way it's
> > > displayed is not allowing to create joins or edit the joined
> fields.
> > >   * I let you imagine the look of the feature attribute form when
> > there
> > > are hundreds of directly and indirectly linked tabled. This is
> just
> > > not usable if we display all of them directly like that. Just
> look
> > > at the attached screen shot that shows what happens by default
> with
> > > only 3 tables. It's already a mess.
> > >
> > > Now, what I propose is:
> > >
> > >   * Not expand the relation widget (QgsCollapsibleGroupBox) by
> default
> > > and build it's content only when it is expanded the first time
> > > (think of what would happen when you have loops in the schema).
> > >   * Show N-1 relations as well, in a collapsed by default
> > > 

Re: [Qgis-developer] Visualisation of relations

[Matthias Kuhn]

Hi Patrick,

for the side that contains the foreign key, there is the "relation
reference" widget which has a configuration option "show embedded form"
(I haven't used it in years and a quick check on it didn't work, so
maybe it needs fixing).

Agreed, collapsed by default makes sense for huge models. For small ones
it's a bit strange though. Another approach would be to put them on
separate tabs by default, I think that could look quite nice also. What
do you think?

Regards
Matthias

On 10/31/2016 09:54 AM, Patrick Valsecchi wrote:
> Hi Matthias,
> 
> My screenshot shows only 1:N links. N:1 links are not supported. By N:1,
> I mean the relations from the side that contains the foreign key. If I
> open the form for the "appart" layer, it doesn't show the linked "maison".
> 
> Yes, the collapsed state is remembered, but the default should be
> collapsed. If the default is to open everything, the GUI is going to
> explode if we have hundreds of linked tables.
> 
> Thanks and CU.
> 
> On Sun, Oct 16, 2016 at 8:57 AM, Matthias Kuhn  > wrote:
> 
> Hi Patrick,
> 
> Making forms and relations more usable is always welcome.
> 
> What exactly are the problems you have with the current solution?
> I see that you mentioned the lack of the N:1 side which is available
> including add feature, add link, remove feature, remove link pretty much
> the way you describe it. On [1] there is some explanation I wrote on the
> first implementation.
> 
> I think you should have found that since it's shown on the screenshot
> which is attached to your mail.
> 
> Also lazy loading (load when first visible) was introduced once for
> performance reasons and the collapsed state of the group boxes
> containing the QgsRelationEditor widget is remembered.
> 
> So I think that functionality-wise, most of it should be there already.
> With a lot of air left for improvement on the usability side.
> 
> Cheers
> Matthias
> 
> [1] http://blog.vitu.ch/10112013-1201/qgis-relations
> 
> 
> 
> On 10/07/2016 09:27 AM, Patrick Valsecchi wrote:
> > Hi,
> >
> > I'm tasked with making QGIS a bit more usable with complex database
> > schemas having a lot of relations (up to hundreds of linked tables). The
> > INSPIRE people were a bit too inspired when creating their data schemas
> > and now we have to try to make QGIS able to cope with that.
> >
> > My concerns with the current situation (as of QGIS master) are:
> >
> >   * We can specify the relations between the layers at the project
> level
> > (it's now easier with the auto-discover feature for PostGIS and
> > Spatialite). But those are only showing in the QgsAttributeForm for
> > the 1-N side (the side that doesn't have the foreign key). Why not
> > on the N-1 side?
> >   * For showing the N-1 side in the QgsAttributeForm, one can define a
> > Join in the layer's properties, but I don't see the point of having
> > to define it here as well when we have already the relations info at
> > the project level. I see a use for special joins, but for relations,
> > I don't see why we have to define it twice. And the way it's
> > displayed is not allowing to create joins or edit the joined fields.
> >   * I let you imagine the look of the feature attribute form when
> there
> > are hundreds of directly and indirectly linked tabled. This is just
> > not usable if we display all of them directly like that. Just look
> > at the attached screen shot that shows what happens by default with
> > only 3 tables. It's already a mess.
> >
> > Now, what I propose is:
> >
> >   * Not expand the relation widget (QgsCollapsibleGroupBox) by default
> > and build it's content only when it is expanded the first time
> > (think of what would happen when you have loops in the schema).
> >   * Show N-1 relations as well, in a collapsed by default
> > QgsCollapsibleGroupBox, including a way to add a new linked entry,
> > remove the link (put the FK to NULL) and delete it.
> >   * Add a button to open a related feature in a new window.
> >
> > What do you guys think?
> >
> > Thanks.
> >
> >
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org 
> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> > Unsubscribe:
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> >
> ___
> 

Re: [Qgis-developer] Visualisation of relations

[Patrick Valsecchi]

Hi Matthias,

My screenshot shows only 1:N links. N:1 links are not supported. By N:1, I
mean the relations from the side that contains the foreign key. If I open
the form for the "appart" layer, it doesn't show the linked "maison".

Yes, the collapsed state is remembered, but the default should be
collapsed. If the default is to open everything, the GUI is going to
explode if we have hundreds of linked tables.

Thanks and CU.

On Sun, Oct 16, 2016 at 8:57 AM, Matthias Kuhn  wrote:

> Hi Patrick,
>
> Making forms and relations more usable is always welcome.
>
> What exactly are the problems you have with the current solution?
> I see that you mentioned the lack of the N:1 side which is available
> including add feature, add link, remove feature, remove link pretty much
> the way you describe it. On [1] there is some explanation I wrote on the
> first implementation.
>
> I think you should have found that since it's shown on the screenshot
> which is attached to your mail.
>
> Also lazy loading (load when first visible) was introduced once for
> performance reasons and the collapsed state of the group boxes
> containing the QgsRelationEditor widget is remembered.
>
> So I think that functionality-wise, most of it should be there already.
> With a lot of air left for improvement on the usability side.
>
> Cheers
> Matthias
>
> [1] http://blog.vitu.ch/10112013-1201/qgis-relations
>
>
> On 10/07/2016 09:27 AM, Patrick Valsecchi wrote:
> > Hi,
> >
> > I'm tasked with making QGIS a bit more usable with complex database
> > schemas having a lot of relations (up to hundreds of linked tables). The
> > INSPIRE people were a bit too inspired when creating their data schemas
> > and now we have to try to make QGIS able to cope with that.
> >
> > My concerns with the current situation (as of QGIS master) are:
> >
> >   * We can specify the relations between the layers at the project level
> > (it's now easier with the auto-discover feature for PostGIS and
> > Spatialite). But those are only showing in the QgsAttributeForm for
> > the 1-N side (the side that doesn't have the foreign key). Why not
> > on the N-1 side?
> >   * For showing the N-1 side in the QgsAttributeForm, one can define a
> > Join in the layer's properties, but I don't see the point of having
> > to define it here as well when we have already the relations info at
> > the project level. I see a use for special joins, but for relations,
> > I don't see why we have to define it twice. And the way it's
> > displayed is not allowing to create joins or edit the joined fields.
> >   * I let you imagine the look of the feature attribute form when there
> > are hundreds of directly and indirectly linked tabled. This is just
> > not usable if we display all of them directly like that. Just look
> > at the attached screen shot that shows what happens by default with
> > only 3 tables. It's already a mess.
> >
> > Now, what I propose is:
> >
> >   * Not expand the relation widget (QgsCollapsibleGroupBox) by default
> > and build it's content only when it is expanded the first time
> > (think of what would happen when you have loops in the schema).
> >   * Show N-1 relations as well, in a collapsed by default
> > QgsCollapsibleGroupBox, including a way to add a new linked entry,
> > remove the link (put the FK to NULL) and delete it.
> >   * Add a button to open a related feature in a new window.
> >
> > What do you guys think?
> >
> > Thanks.
> >
> >
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Matthias Kuhn]

Hi Patrick,

Making forms and relations more usable is always welcome.

What exactly are the problems you have with the current solution?
I see that you mentioned the lack of the N:1 side which is available
including add feature, add link, remove feature, remove link pretty much
the way you describe it. On [1] there is some explanation I wrote on the
first implementation.

I think you should have found that since it's shown on the screenshot
which is attached to your mail.

Also lazy loading (load when first visible) was introduced once for
performance reasons and the collapsed state of the group boxes
containing the QgsRelationEditor widget is remembered.

So I think that functionality-wise, most of it should be there already.
With a lot of air left for improvement on the usability side.

Cheers
Matthias

[1] http://blog.vitu.ch/10112013-1201/qgis-relations


On 10/07/2016 09:27 AM, Patrick Valsecchi wrote:
> Hi,
> 
> I'm tasked with making QGIS a bit more usable with complex database
> schemas having a lot of relations (up to hundreds of linked tables). The
> INSPIRE people were a bit too inspired when creating their data schemas
> and now we have to try to make QGIS able to cope with that.
> 
> My concerns with the current situation (as of QGIS master) are:
> 
>   * We can specify the relations between the layers at the project level
> (it's now easier with the auto-discover feature for PostGIS and
> Spatialite). But those are only showing in the QgsAttributeForm for
> the 1-N side (the side that doesn't have the foreign key). Why not
> on the N-1 side?
>   * For showing the N-1 side in the QgsAttributeForm, one can define a
> Join in the layer's properties, but I don't see the point of having
> to define it here as well when we have already the relations info at
> the project level. I see a use for special joins, but for relations,
> I don't see why we have to define it twice. And the way it's
> displayed is not allowing to create joins or edit the joined fields.
>   * I let you imagine the look of the feature attribute form when there
> are hundreds of directly and indirectly linked tabled. This is just
> not usable if we display all of them directly like that. Just look
> at the attached screen shot that shows what happens by default with
> only 3 tables. It's already a mess.
> 
> Now, what I propose is:
> 
>   * Not expand the relation widget (QgsCollapsibleGroupBox) by default
> and build it's content only when it is expanded the first time
> (think of what would happen when you have loops in the schema).
>   * Show N-1 relations as well, in a collapsed by default
> QgsCollapsibleGroupBox, including a way to add a new linked entry,
> remove the link (put the FK to NULL) and delete it.
>   * Add a button to open a related feature in a new window.
> 
> What do you guys think?
> 
> Thanks.
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Neumann, Andreas]

Hi Patrick, 

Matthias Kuhn, the one who knows about this the best, is currently out
of office / on holidays. I think he is back next week. 

I would probably wait for his review. 

Thanks and greetings, 

Andreas 

On 2016-10-12 09:48, Patrick Valsecchi wrote:

> No answer. I think I'll move forward with my proposal.
> 
> Thanks. 
> 
> On Fri, Oct 7, 2016 at 9:27 AM, Patrick Valsecchi 
>  wrote:
> 
>> Hi,
>> 
>> I'm tasked with making QGIS a bit more usable with complex database schemas 
>> having a lot of relations (up to hundreds of linked tables). The INSPIRE 
>> people were a bit too inspired when creating their data schemas and now we 
>> have to try to make QGIS able to cope with that.
>> 
>> My concerns with the current situation (as of QGIS master) are:
>> 
>> * We can specify the relations between the layers at the project level (it's 
>> now easier with the auto-discover feature for PostGIS and Spatialite). But 
>> those are only showing in the QgsAttributeForm for the 1-N side (the side 
>> that doesn't have the foreign key). Why not on the N-1 side?
>> * For showing the N-1 side in the QgsAttributeForm, one can define a Join in 
>> the layer's properties, but I don't see the point of having to define it 
>> here as well when we have already the relations info at the project level. I 
>> see a use for special joins, but for relations, I don't see why we have to 
>> define it twice. And the way it's displayed is not allowing to create joins 
>> or edit the joined fields.
>> * I let you imagine the look of the feature attribute form when there are 
>> hundreds of directly and indirectly linked tabled. This is just not usable 
>> if we display all of them directly like that. Just look at the attached 
>> screen shot that shows what happens by default with only 3 tables. It's 
>> already a mess.
>> 
>> Now, what I propose is: 
>> 
>> * Not expand the relation widget (QgsCollapsibleGroupBox) by default and 
>> build it's content only when it is expanded the first time (think of what 
>> would happen when you have loops in the schema).
>> * Show N-1 relations as well, in a collapsed by default 
>> QgsCollapsibleGroupBox, including a way to add a new linked entry, remove 
>> the link (put the FK to NULL) and delete it.
>> * Add a button to open a related feature in a new window.
>> 
>> What do you guys think? 
>> 
>> Thanks.
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Visualisation of relations

[Patrick Valsecchi]

No answer. I think I'll move forward with my proposal.

Thanks.

On Fri, Oct 7, 2016 at 9:27 AM, Patrick Valsecchi <
patrick.valsec...@camptocamp.com> wrote:

> Hi,
>
> I'm tasked with making QGIS a bit more usable with complex database
> schemas having a lot of relations (up to hundreds of linked tables). The
> INSPIRE people were a bit too inspired when creating their data schemas and
> now we have to try to make QGIS able to cope with that.
>
> My concerns with the current situation (as of QGIS master) are:
>
>- We can specify the relations between the layers at the project level
>(it's now easier with the auto-discover feature for PostGIS and
>Spatialite). But those are only showing in the QgsAttributeForm for the 1-N
>side (the side that doesn't have the foreign key). Why not on the N-1 side?
>- For showing the N-1 side in the QgsAttributeForm, one can define a
>Join in the layer's properties, but I don't see the point of having to
>define it here as well when we have already the relations info at the
>project level. I see a use for special joins, but for relations, I don't
>see why we have to define it twice. And the way it's displayed is not
>allowing to create joins or edit the joined fields.
>- I let you imagine the look of the feature attribute form when there
>are hundreds of directly and indirectly linked tabled. This is just not
>usable if we display all of them directly like that. Just look at the
>attached screen shot that shows what happens by default with only 3 tables.
>It's already a mess.
>
> Now, what I propose is:
>
>- Not expand the relation widget (QgsCollapsibleGroupBox) by default
>and build it's content only when it is expanded the first time (think of
>what would happen when you have loops in the schema).
>- Show N-1 relations as well, in a collapsed by default
>QgsCollapsibleGroupBox, including a way to add a new linked entry, remove
>the link (put the FK to NULL) and delete it.
>- Add a button to open a related feature in a new window.
>
> What do you guys think?
>
> Thanks.
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer