[QGIS-Developer] Adding Field Calculator Functions - Best Practices / Avoiding Name Conflicts

[Nyall Dawson]

On Thu, 17 Sep 2020 at 23:06, C Hamilton <adenaculture at gmail.com> wrote:
>
> Nyall,
>
> I really should get into some core development, but I have been hesitant since my C++ programming skills are 10 years out of date. How time flies.

Adding expression functions like this is actually a great place to
start, because the changes are very self-contained and isolated to
basically one file
(https://github.com/qgis/QGIS/blob/master/src/core/expression/qgsexpressionfunction.cpp)

It's usually possible to find an existing function which does a
similar thing as your new function and copy/paste the other function's
code. E.g. you could look at something like the to_dm function, which
is basically just two changes:

Registering the function to the expression engine:
https://github.com/qgis/QGIS/blob/master/src/core/expression/qgsexpressionfunction.cpp#L6031

and

The function implementation:
https://github.com/qgis/QGIS/blob/master/src/core/expression/qgsexpressionfunction.cpp#L2096
(calls a function defined here
https://github.com/qgis/QGIS/blob/master/src/core/expression/qgsexpressionfunction.cpp#L2056).

> Where is the best place to start if I were to try to start porting some of the functions into the core QGIS. Some of this would require incorporating additional C modules/libraries such as MGRS, Plus Codes, etc into the code base.

I'd start with the easiest one first. Is there a function which is
self-contained and which doesn't require external libraries? That
would be the best starting point, as you'd use it to learn the QGIS
build system and PR submission/review process.

Might be worth your time dropping in on a QHackDay
(http://blog.qgis.org/2020/08/21/say-hello-to-the-qhackfriday/) if
you'd like to discuss face-to-face (virtually)!)

Nyall

>
> Thanks,
>
> Calvin
>
> On Wed, Sep 16, 2020 at 6:44 PM Nyall Dawson <nyall.dawson at gmail.com> wrote:
>>
>> On Thu, 17 Sep 2020 at 01:55, C Hamilton <adenaculture at gmail.com> wrote:
>> >
>> > Greetings,
>> >
>> > Because of a user request I have been starting to expose Lat Lon Tools coordinate format conversion functions. I found out today that if you accidentally call one of your functions the same name as one of the existing functions, it causes QGIS to crash immediately. It got me thinking about the best practices for releasing field calculator functions. As other developers create their own field calculator functions there is the potential for major problems. I would say that if there is a name conflict it shouldn't crash QGIS.
>> >
>> > These are the function names I currently have in Lat Lon Tools.
>> >
>> > mgrs, mgrs_100km, mgrs_east, mgrs_north, mgrs_to_point
>> >
>> > Here are additional function names I have added that have not yet been uploaded to the QGIS plugin repo and more are on the way
>> >
>> > utm, utm_epsg, utm_hemisphere, utm_to_point, utm_zone, dms, ddmmss
>> >
>> > I like simple function names, but because of concerns that there could be name conflicts with other QGIS plugin developers I am wondering if a plugin name prefix should be added such as ll_mgrs for the Lat Lon Tools mgrs conversion function.
>> >
>> > What are your thoughts?
>>
>> These sound like really useful functions of widespread appeal. Have
>> you considered implementing them in QGIS itself? I'd be happy to
>> assist!
>>
>> Nyall
>>
>>
>>
>> >
>> > Thanks,
>> >
>> > Calvin
>> > _______________________________________________
>> > QGIS-Developer mailing list
>> > QGIS-Developer at lists.osgeo.org
>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer