On 31 August 2016 at 21:20, Matthias Kuhn <[email protected]> wrote: > Hi, > > On 08/31/2016 12:41 PM, Nyall Dawson wrote: >> On 31 August 2016 at 16:56, Matthias Kuhn <[email protected]> wrote: >>> Hi, >>> >>> I've already got some ideas because it affects QField (where I'm about >>> to drop the whole gui lib) as well. >>> >>> Implementing this in QGIS instead of QField is much preferred. >>> >>> From a technical perspective, I would propose to use a tree-like >>> structure based on QVariants. >>> They've got all it takes for this: >>> >>> QVariantMap can handle tree structures of key value pairs (for XML child >>> nodes), a key "__attributes__" can be added to save the XML element >>> attributes into. >>> >>> This way, the information can be read without knowledge about a >>> particular widget's implementation details and is available directly >>> from core. The widgets (or whatever part) can add the semantics on top >>> in their own library. >> >> Just to clarify - are you proposing that only a map of widget >> configuration is moved to core? I'd say the representValue function >> for each widget should also should be moved across, otherwise we'll >> end up with multiple code paths reimplementing the logic from each >> widget + plugins having to redo this themselves. > > Good point, > > that will also be nice to have in core. > > In this case we'll end up with two registries and two factories > (although only a few widgets will need core functionality). > Or did you have a different idea in mind?
This is what I was thinking - I can't think of a nice way around this. Nyall > > Matthias _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
