QGIS » QGIS Application

That would indeed be very useful and a killer feature for QGIS' next version.

Other practical uses for expression based labeling:
- Nicer display of INT/FLOAT values (i.e. "$hectares + ' ha'")
- Ability to make basic string manipulation to further differentiate label types (lowercase(), uppercase(), capitalize(), etc.)

Does that branch still exist somewhere, Nathan?

Opps yeah it does; I changed my github username it's now here: https://github.com/NathanW2/Quantum-GIS/tree/expression-labels

This is what I have done so far with the dialog.

The expression based labeling works I'm just cleaning up the UI and the code in order to send a patch.

Please note also #4080. I think this one, #3843 and #4080 should be considered in somehow consistent way.
There is also #1419

/me salivates thinking qgis is close to get expression based labeling

Nathan, are you planning to add basic functions to manipulate strings / numbers? In no particular order, I'm thinking:
- uppercase(string)
- lowercase(string)
- capitalize(string)
- number_format(number, decimal_char, thousands_char).

Sure adding those kinds of things should be pretty easy, it's mainly just a matter of adding them to the QgsExpression class. Martin ala wonder-sk is the guy that can add that stuff in pretty easily as he just redesigned the expression parser.

I think the goal is to have as close to SQL syntax as possible, so we would use UPPER.
I would open another ticket if you want to get that stuff added in.

nirvn - wrote:

/me salivates thinking qgis is close to get expression based labeling

Nathan, are you planning to add basic functions to manipulate strings / numbers? In no particular order, I'm thinking:
- uppercase(string)
- lowercase(string)
- capitalize(string)
- number_format(number, decimal_char, thousands_char).

FYI: there are already upper(string) and lower(string). For capitalization it seems that initcap(string) is the usual choice for the function name (postgresql, oracle, ms sql). For number formatting I do not know if there is any standard, but keep in mind that some people also would like to specify the number of digits before/after decimal point and optionally add some padding (with zeros or spaces).

Nathan Woodrow wrote:

This is what I have done so far with the dialog.

The expression based labeling works I'm just cleaning up the UI and the code in order to send a patch.

Nathan, just wondering - is that a completely new dialog? Because currently we have a similar dialog for field calculator (qgsfieldcalculatorbase.ui) and for query builder (qgsquerybuilderbase.ui). This is already suboptimal, so a new dialog should be avoided.

Ideally we should have a reusable widget that provides the text area, list of operators / functions with help, and maybe a way how to get a sample (or all values) from a selected column. Such a widget would be then embedded into all the dialogs that do something with expressions.

Yeah it is a new dialog however it is implemented as a reusable Widget with the intention to use it any where that needs expressions eg QueryBuilder and Field Calculator.

I was going to use the existing ones but they both didn't really serve a generic solution that could be adapted into any situation; they also weren't every expandable with the growing list of functions.

So yes my overall goal with the widget is to replace the others, remove some code logic duplication and create a more uniformed UI.

Thoughts?

Ok, that makes sense: to develop a new reusable widget and then use it also for the field calculator and search query builder.

I think you have a good directions, a big grid of buttons with all the operators and functions is not sustainable. Have you done some research how such editor looks in other software? Doing a google image search for "expression editor" yields quite a lot of examples. It would be good to compare them and identify the good, the bad and the ugly ones.

Would it be possible to implement a "substring" operator too? That way, users could reformat date strings from "YYYY-mm-dd" to "dd.mm.YYYY" for example.

Anita, "substring" operator is there, too. The syntax is substr(text, from, len) where "from" is indexed from one.

Can I suggest a discussion/brainstorm on the UI?
I can imagine that with the full list of operators and a large number of fields it could become annoying scrolling up and down repeatedly. It might be slightly better to put Operators, Geometry and Fields on different tabs or something.

There is a real time search at the top that limits the entries to show only stuff with that keyword.

The tab idea is interesting although I worry that you run into a problem of when do you stop making new tabs for lists, the other lists could, in future, get just as big. I added to the search to reduce this problem.

Martin, your thoughts?

I am also in favor of keeping the current design. Further improvements may be added later if needed.

Nathan, thanks a gazillion times for this.

Nathan, IMO a capitalize('string') function would be really, really useful alongside uppercase / lowercase.

nirvn, no worries, Hopefully people find it useful. I would open a ticket if you want some other functions added.

Martin, thanks for the merge :).

Nathan, good idea.

Bug #4425: capitalize() function
Bug #4426: number_format() function

Cheers.