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 <matth...@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 <matth...@opengis.ch > > <mailto:matth...@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@lists.osgeo.org <mailto:Qgis-developer@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@lists.osgeo.org <mailto:Qgis-developer@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@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer