[Qgis-developer] Decoupling core/data and GUI part of widgets in 3.0

[Matthias Kuhn]

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.

So that's the inoffical QEP, I'd say we skip the official part.

Matthias

On 08/31/2016 08:48 AM, Richard Duivenvoorde wrote:
> 
> +1 from me too
> 
> As a project we should really take the opportunity of a 3.0 branch to
> review this kind of architectural cleanups and focus on a healthy code
> base more then on new features for the .0 version, in my opinion.
> 
> best off course if core dev's take the lead in this
> 
> Regards,
> 
> Richard
> 
> 
> 
> On 31-08-16 08:37, Nathan Woodrow wrote:
>> I'm a big +1 on that.  I will add my notes on a QEP if one is opened
>>
>> (Hopefully I can be a bit more active in the project after a bit of a break)
>>
>> - Nathan
>>
>> On Wed, Aug 31, 2016 at 4:29 PM, Neumann, Andreas <a.neumann at carto.net
>> <mailto:a.neumann at carto.net>> wrote:
>>
>>     Hi all, Hi Nyall, Matthias and Denis,
>>
>>     After some discussion with Nyall we stumbled again over the
>>     inconvenience that widgets in QGIS mix data (core) and GUI part.
>>     This effects many places in QGIS where you want to address the
>>     display value of a widget instead of the raw value: QGIS Server
>>     (e.g. GetFeatureInfo Requests), Print Composer, Labels, Save to
>>     Spreadsheet with human readable values, and many more.
>>
>>     So before people are introducing more and more widgets (which is
>>     nice) I would suggest to first improve our widget infrastructure for
>>     QGIS 3.0 to decouple the Core/data part from the GUI part, which
>>     would allow code to access all widget configuration and
>>     properties without having to deal with the GUI part of the widget.
>>     Nyall mentioned that the symbology rendering separates this nicely,
>>     but the attribute widgets do not.
>>
>>     Nyall suggested to do a QEP for that to discuss the implications and
>>     how this can be cleanly designed.
>>
>>     Matthias - since you are "the widget guy" - do you want to take a
>>     lead on this QEP? Or should I ask Nyall?
>>
>>     Thanks,
>>
>>     Andreas
>>
>>      
>>
>>     _______________________________________________
>>     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
>> 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 at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>