On Thu, 17 Sep 2020 at 23:06, C Hamilton <adenacult...@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.daw...@gmail.com> wrote: >> >> On Thu, 17 Sep 2020 at 01:55, C Hamilton <adenacult...@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-develo...@lists.osgeo.org >> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
