[QGIS-Developer] Popup window within Processing crashes QGIS

[Nyall Dawson]

On Mon, 3 Sep 2018 at 23:09, C Hamilton <adenaculture at gmail.com> wrote:
>
> Nyall,
>
> I have been working on an alternative KML/KMZ importing tool and a tool to expand HTML tables within the description field containing tag/value elements into fields in the table.  The reason for another importer is that the GDAL implementation is in some sense too smart. The situation is that if there are many folders in a KML, QGIS imports each as a layer and is very slow at importing or crashes during the import if there happens to be hundreds of layers. This also happens using ArcGIS. I am assuming that both use GDAL and in some respects GDAL tries to do too much. Consequently, I wrote this KML plugin to import KML/KMZ files in the way we wanted them. The following is the capability prior to processing.

Sounds handy -- I've hit this in the past too. Those HTML tables
inside KML really annoy me a lot.

> I have already converted this importer to processing. The second function that expands HTML tables in the description field does a first pass to see if there are any tables and makes note of the tags/fields to be created. It then pops up a dialog box to allow the user to select what fields they want expanded. They only way you could do this in processing, since I can't pop up a selection box, is to expand all potential tags/fields, but the users don't want to do this.

Ok, so in this case I'd suggest:
- Make sure your code is nicely partitioned, separating out the core
functionality from the gui component
- Add a "callback" type argument within your converter, which is used
to select which fields to import
- Make your plugin add both a processing algorithm AND the
non-processing, interactive action
- The processing algorithm sets a callback which returns ALL fields
always, with no user interaction. The Interactive action passes a
callback which shows the field selection dialog.

This gives approach gains you:
- A single unified code base, with clear gui/logic separation (so also
easy to write unit tests for)
- Makes the users who want an interactive choice happy
- Still exposes your functionality from within Processing for users
who want everything, or want to use this function within a model OR
from another plugin/Python script.

That's the "canonical" approach to take here.

Nyall

> I have debated whether I should make this a separate plugin in or add the functionality to Lat Lon Tools. I already have conversion routines such as MGRS conversion and "Plus Codes" in Lat Lon Tools. What are your thoughts? Should this be added to Lat Lon Tools or a separate plugin?

Separate plugin -- they are very different functionalities, and
plugins work best when they expose "atomic" functions.

Nyall


>
> Calvin
>
>
> On Fri, Aug 31, 2018 at 5:06 PM, Nyall Dawson <nyall.dawson at gmail.com> wrote:
>>
>> On Fri, 31 Aug 2018 at 22:24, C Hamilton <adenaculture at gmail.com> wrote:
>> >
>> > Thanks Nyall!!! Unfortunately I was trying to make this a processing routine when I shouldn't have. It is good to know the boundaries. This function really requires user interactivity.
>>
>> Mind sharing the general function of the plugin? There may still be a
>> way to make this work within Processing.
>>
>> Regards,
>> Nyall
>>
>> >
>> > Calvin
>> >
>> > On Thu, Aug 30, 2018 at 9:27 PM, Nyall Dawson <nyall.dawson at gmail.com> wrote:
>> >>
>> >> On Thu, 30 Aug 2018 at 23:38, C Hamilton <adenaculture at gmail.com> wrote:
>> >> >
>> >> > I have an algorithm that during execution gathers information from the data and then pops up a window for the user to select what the user would like to do.
>> >> >
>> >> > Is this possible in the Processing framework? I have tried doing this in processAlgorithm and it crashes QGIS. Here is how I call the popup window.
>> >>
>> >> No - this is not supported and goes against the very fundamental
>> >> design of Processing. Argggh! ;)
>> >>
>> >> But seriously, Processing was designed with the intention that all
>> >> user choices are made up-front. This allows algorithms to be nicely
>> >> executed inside of models, without the model halting mid-way waiting
>> >> for user input. It also allows algorithms, scripts, models, etc to be
>> >> run from headless environments such as console scripts.
>> >>
>> >> In this case, you're getting a crash because you're trying to create
>> >> GUI components from your algorithm which is being executed in a
>> >> background thread. This is a big no-no in Qt land, and usually results
>> >> in a crash.
>> >>
>> >> Nyall
>> >>
>> >>
>> >> >         fieldsDialog = SelectionDialog(self.tableFeatures)
>> >> >         fieldsDialog.exec_()
>> >> >         items = fieldsDialog.selected
>> >> >
>> >> > Here is the beginning of the SelectionDialong class.
>> >> >
>> >> > class SelectionDialog(QDialog, FIELDS_CLASS):
>> >> >     def __init__(self, feat, parent=None):
>> >> >         super(SelectionDialog, self).__init__(parent)
>> >> >         self.setupUi(self)
>> >> >
>> >> > Prior to Processing I passed in iface.mainWindow() as the parent. Is there a proper parent in Processing to pass? Perhaps this is the reason it is crashing.
>> >> >
>> >> > class SelectionDialog(QDialog, FIELDS_CLASS):
>> >> >     def __init__(self, iface, feat):
>> >> >         super(SelectionDialog, self).__init__(iface.mainWindow())
>> >> >         self.setupUi(self)
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Calvin
>> >
>> >
>
>