[QGIS-Developer] QGIS3 plugin migration issue

Nyall Dawson nyall.dawson at gmail.com
Thu Apr 5 17:07:53 PDT 2018 

On 5 April 2018 at 15:11, André William <wss.andre at gmail.com> wrote:
>> My thinking here is whether this needs to be supported officially -
>> e.g. by making the panel wider by default. Alternatively we could add
>> a method to QgsProcessingAlgorithmDialogBase to handle resizing of
>> this panel.
>
>
> To be honest, it seems like I'm the only one with this issue. I guess as
> long as the workaround does the job, I wouldn't bother with it.

Sure. Just wrap it in a try block so it won't have the possibility of
breaking in future and you'll be right.

> As for the issues/projects that you mentioned, what seemed like something I
> could tackle is the missing algorithms from PostGIS, since I've got more
> experience with it. Also, it really does sound like a lot of fun to
> implement!
>
>> I'm happy to mentor. Just let me know.
>
>
> Thank you Nyall, that would be really cool!
> Could you give me some pointers as to how should I go about the PostGIS
> algs? Like what classes should be extended, what methods should be
> implemented or anything else I should pay attention to?

I'd start with an easy one - implementing a geometry "scale"
algorithm, since this doesn't require adding anything new to the
QgsGeometry class.

What you'd be doing here is utilising the "QgsGeometry::transform(
QTransform transform,.... )" method. You'd build a scaling transform
using QTransform::fromScale and then pass that to the QgsGeometry
method, so that every coordinate in the geometry is scaled by the
scaling transform.

Use the QgsTranslateAlgorithm class as a starting point to base your
new algorithm off. Most of this will then break down to renaming
offset parameters and variables to scale, and then using
QgsGeometry::transform in the processFeature method instead of
QgsGeometry::translate. There's some code there which won't be
required anymore - specifically the logic about adding z/m values to
geometries if they don't already exist (since z/m would only be scaled
if they already exist). So the whole outputWkbType method can be
dropped too, as the algorithm won't be changing the WKB type in any
way.

After you've made the new class you need to make sure it's registered
to the QgsNativeAlgorithms provider, see
QgsNativeAlgorithms::loadAlgorithms().

That should be all that's required to get the algorithm implemented,
then it's just a matter of adding unit tests (can discuss this in a
PR).

This would be a good project to get your head around the basics of
implementing c++ algorithms in QGIS without any complicating details.

Good luck!
Nyall



>
> André
>
> 2018-04-03 19:58 GMT-03:00 Nyall Dawson <nyall.dawson at gmail.com>:
>>
>> On 4 April 2018 at 05:29, André William <wss.andre at gmail.com> wrote:
>> > Thank you Nyall, I understand.
>> > The reason I needed to resize the window was to better fit some image
>> > content in my HTML help.
>>
>> My thinking here is whether this needs to be supported officially -
>> e.g. by making the panel wider by default. Alternatively we could add
>> a method to QgsProcessingAlgorithmDialogBase to handle resizing of
>> this panel.
>>
>> > Taking the opportunity, I'm a C++ and Python developer and I would love
>> > to
>> > contribute on the project. Is there any need for help in the Processing
>> > Framework (since I'm already a bit familiar with it) or in others areas?
>>
>> Heck yes! There's a TON of work which processing would greatly benefit
>> from. Here's a very short brain-dump of potential high-value projects:
>>
>> - if you're a user of any of the 3rd party providers (GDAL, GRASS,
>> SAGA), these need a lot of love. There's lots of open tickets against
>> them, some of which would be quick fixes for someone more familiar
>> with the underlying provider library. Similarly if you're on Win or
>> OSX there's quite a few open tickets against these providers (most
>> testing is done on Linux)
>>
>> - if you're a model user, a nice project would be improving the inputs
>> panel in the modeler dialog. It's been discussed (somewhere, can't
>> find it now) that this panel should be reworked to be a list of inputs
>> used within the model, with + / - buttons to add a new input and
>> remove a selected input. And then we could add up/down buttons to
>> allow inputs to be reordered for models, since they are currently just
>> shown in a semi-random order and there's no way for users to
>> reorganize them logically. All the API stuff should be in place for
>> this, it's just Python GUI work that's needed.
>>
>> - another high value task is porting the QGIS algorithms from Python
>> to c++ (for speed and stability). At the same time we do this we
>> upgrade each algorithm to support "data defined" parameter values
>> (e.g. buffer width based on expressions!). The goal here is to move
>> all the QGIS algorithms across to c++, EXCEPT those which have
>> dependencies on Python libraries.
>>
>> - there's rough notes on
>>
>> https://github.com/nyalldawson/QGIS/wiki/Processing-Algorithm-Bugs-and-Enhancements
>> concerning improvements we can make to existing algorithms which would
>> be fantastic to see explored
>>
>> - Or, the funnest processing job, adding more algorithms! There's a
>> rough wish-list at
>> https://github.com/nyalldawson/QGIS/wiki/Algorithm-hit-list , some of
>> which are just a matter of exposing existing QgsGeometry methods as
>> processing algorithms (e.g. exposing QgsGeometry::transform(
>> QTransform .... ) as an algorithm to allow rotate/shear/scale
>> transforms), and some of which require adding wrappers to GEOS
>> functions to QgsGeometry (GEOSMinimumWidth_r,
>> GEOSMinimumClearanceLine_r, GEOSNode_r, GEOSSharedPaths_r) and then
>> exposing as processing algorithms. Others need javascript->c++ ports
>> of functionality from turf/mapbox js libraries, if that kind of thing
>> interests you.
>>
>> > I would probably need some guidance at first but I've been using QGIS
>> > and
>> > developing plugins for some time now, so I guess it wouldn't be too big
>> > a
>> > learning curve.
>>
>> I'm happy to mentor. Just let me know.
>>
>> Nyall
>>
>>
>> >
>> > André
>> >
>> > 2018-04-03 0:29 GMT-03:00 Nyall Dawson <nyall.dawson at gmail.com>:
>> >>
>> >> On 31 March 2018 at 14:06, André William <wss.andre at gmail.com> wrote:
>> >> > After some digging, I found that while the textShortHelp object is
>> >> > not
>> >> > directly available in the AlgorithmDialog class anymore, i was able
>> >> > to
>> >> > access it like this:
>> >> >>
>> >> >> shortHelpObj = dlg.findChild(QTextBrowser, 'textShortHelp')
>> >> >
>> >> > Is this the expected behavior?
>> >>
>> >> None of this is in stable API, so can change between QGIS versions
>> >> (including within minor versions/patch releases).
>> >>
>> >> Stable API for processing is:
>> >> - the classes within the core library (unless they are explicitly
>> >> marked as non-stable, e.g.  the modeler related classes)
>> >> - the base GUI "WidgetWrapper" class (NOT any of its subclasses)
>> >> - some methods from the processing namespace:
>> >>     - processing.algorithmHelp()
>> >>     - processing.run()
>> >>     - processing.runAndLoadResults()
>> >>     - processing.createAlgorithmDialog()
>> >>     - processing.execAlgorithmDialog()
>> >>
>> >> So, in short, unfortunately this approach is always going to be
>> >> fragile. Better wrap it in a big try block! ;)
>> >>
>> >> I gather you're trying to force the "help" panel to resize when the
>> >> dialog is opened. Is there a particular reason why you need to do
>> >> this?
>> >>
>> >> Nyall
>> >>
>> >>
>> >> >
>> >> > André W.
>> >> >
>> >> > 2018-03-30 18:54 GMT-03:00 André William <wss.andre at gmail.com>:
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> I'm porting an existing Geoprocessing Algorithm plugin to QGIS 3 and
>> >> >> I'm
>> >> >> having some trouble customizing the default dialog.
>> >> >> On QGIS 2.x the following code worked:
>> >> >>
>> >> >>> class TestAlgorithm(GeoAlgorithm):
>> >> >>>     INPUT = 'INPUT'
>> >> >>>     OUTPUT = 'OUTPUT'
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>     def getCustomParametersDialog(self):
>> >> >>>         customDialog = AlgorithmDialog(self)
>> >> >>>         customDialog.textShortHelp.setFixedWidth(450)
>> >> >>>         return customDialog
>> >> >>
>> >> >>
>> >> >> On QGIS 3 however, the getCustomParametersDialog() method is gone. I
>> >> >> assumed it was replaced by the new createCustomParametersWidget(),
>> >> >> but
>> >> >> unfortunately this method doesn't seem to get called by the parent
>> >> >> class:
>> >> >>
>> >> >>>     def createCustomParametersWidget(self, parent):
>> >> >>>         customDialog = AlgorithmDialog(self)
>> >> >>>         customDialog.textShortHelp.setFixedWidth(450)
>> >> >>>         return customDialog
>> >> >>
>> >> >>
>> >> >> I also tried manually creating the dialog, but I get a message
>> >> >> saying
>> >> >> that
>> >> >> the 'AlgorithmDialog' object has no attribute 'textShortHelp'.
>> >> >>
>> >> >>> alg =
>> >> >>>
>> >> >>>
>> >> >>> QgsApplication.processingRegistry().algorithmById('test:testAlgorithm')
>> >> >>> dlg = AlgorithmDialog(alg)
>> >> >>> dlg.textShortHelp.setFixedWidth(450)
>> >> >>> dlg.show()
>> >> >>
>> >> >>
>> >> >> Any thoughts?
>> >> >>
>> >> >> Thanks in advance!
>> >> >> André
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > 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
>> >
>> >
>
>

More information about the QGIS-Developer mailing list