Hi Nyall,
Thank you very much for your detailed reply. Good to hear that there is
an interest in making this happen. Is this something that could be added
during QGIS 3.x life span or would this have to wait for QGIS 4.x? Would
this be something for a 2021 QGIS grant? About my specific scenario:
I was looking for a to_boolean() conversion function - but it doesn't
exist. Would the alternative "eval(@debugging)" be the way here - are
there any downsides of using eval() in this context? @debugging would
hold a string 'true' or 'false'. Greetings, Andreas
On 2020-06-12 02:15, Nyall Dawson wrote:

On Thu, 11 Jun 2020 at 01:26, Andreas Neumann <[email protected]> wrote:
Hi,

I have a question about the variables that can be defined on different scopes. 
They are most of the times (or always?) strings, if I manually define them - 
right?

If you manually define them, then yes -- they are always strings.

Some of the automatic variables might be of a different type (like date, layer, 
etc.)

Correct. The underlying API allows for any variant type value (just
like expressions), so potentially a variable could be a int, date,
datetime, string, list, map, interval, feature, etc...

Can I also manually define a "typed" variable? E.g. a boolean true instead of 
'true' as a string?

Only via PyQGIS, not via the UI.

It's been requested in the past that we support expose an option for
these. And I'd like to see this happen, because then we could improve
the UI for entering variable values in the variable list widget. E.g.
if a variable has been defined on a project level as a "color" type
variable, it would be nice to make it so that when you override this
variable for a particular layout item you get a color picker widget.
And similarly, if you defined a variable to be of the type "font
name", then the tree widget could show a drop down list of available
fonts. It would certainly help make them more accessible.

It's actually somewhat of a dream of mine to expose variable editing
better in the QGIS UI to users. E.g. - via variables its completely
possible to make symbols which alter their appearance. So already have
this concept of "smart symbols", where you could have a marshland
symbol which alters its appearance based on variables like
"@height_of_vegetation" and "@density_of_vegetation" and
"@health_of_vegetation". That's possible today. But to modify these
variables you need to go into the raw variable editor for the layer
and tweak their. What would be great is if we did things like expose
them at the symbol selector dialog -- so that if a user picks your
"marshland" smart symbol from the library, they don't see all the
underlying symbol layers and those settings, but instead just see
widgets for tweaking these specific @height_of_vegetation/...
variables.  This is where "typed" variables would be a necessity!

Nyall

That way I could directly use variables without having to add CASE WHEN END 
statements ...

My use case would be to have a boolean "debugging" variable. If it is set to 
true, then certain parts of the form with internal IDs would be visible, if set to false, 
they would be hidden.

Thanks,

Andreas

_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to