[Qgis-developer] Visualisation of relations
Patrick Valsecchi
patrick.valsecchi at camptocamp.com
Mon Oct 31 05:26:36 PDT 2016
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 <matthias at opengis.ch> 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 <matthias at opengis.ch
> > <mailto:matthias at opengis.ch>> 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
> > <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 at lists.osgeo.org <mailto:Qgis-developer at lists.
> osgeo.org>
> > > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > <http://lists.osgeo.org/mailman/listinfo/qgis-developer>
> > > Unsubscribe:
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > <http://lists.osgeo.org/mailman/listinfo/qgis-developer>
> > >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.
> osgeo.org>
> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > <http://lists.osgeo.org/mailman/listinfo/qgis-developer>
> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > <http://lists.osgeo.org/mailman/listinfo/qgis-developer>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20161031/82e2652f/attachment.html>
More information about the Qgis-developer
mailing list