On Mon, 3 Sep 2018 at 23:09, C Hamilton <[email protected]> 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 <[email protected]> wrote: >> >> On Fri, 31 Aug 2018 at 22:24, C Hamilton <[email protected]> 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 <[email protected]> >> > wrote: >> >> >> >> On Thu, 30 Aug 2018 at 23:38, C Hamilton <[email protected]> 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 >> > >> > > > _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
