Re: [QGIS-Developer] Popup window within Processing crashes QGIS
On Thu, 30 Aug 2018 at 23:38, C Hamilton 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 QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [1526] LAStools approval notification.
Plugin LAStools approval by pcav. The plugin version "[1526] LAStools 0.4 Experimental" is now approved Link: http://plugins.qgis.org/plugins/LAStools/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Popup window within Processing crashes QGIS
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. 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 QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [1408] EasyTemplatePrint approval notification.
Plugin EasyTemplatePrint approval by pcav. The plugin version "[1408] EasyTemplatePrint 0.1 Experimental" is now approved Link: http://plugins.qgis.org/plugins/EasyTemplatePrint/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [1528] Standard Distance approval notification.
Plugin Standard Distance approval by pcav. The plugin version "[1528] Standard Distance 1.0.0" is now approved Link: http://plugins.qgis.org/plugins/StandardDistance/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [1526] LAStools approval notification.
Plugin LAStools approval by pcav. The plugin version "[1526] LAStools 0.3 Experimental" is now approved Link: http://plugins.qgis.org/plugins/LAStools/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [629] Networks approval notification.
Plugin Networks approval by pcav. The plugin version "[629] Networks 2.0.2" is now approved Link: http://plugins.qgis.org/plugins/networks/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [440] Visibility Analysis approval notification.
Plugin Visibility Analysis approval by pcav. The plugin version "[440] Visibility Analysis 0.6.3 Experimental" is now approved Link: http://plugins.qgis.org/plugins/ViewshedAnalysis/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [1410] ImportPhotos approval notification.
Plugin ImportPhotos approval by pcav. The plugin version "[1410] ImportPhotos 1.2" is now approved Link: http://plugins.qgis.org/plugins/ImportPhotos/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [1529] DistanceCartogram approval notification.
Plugin DistanceCartogram approval by pcav. The plugin version "[1529] DistanceCartogram 0.1" is now approved Link: http://plugins.qgis.org/plugins/dist_cartogram/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [1377] TlugProcessing approval notification.
Plugin TlugProcessing approval by pcav. The plugin version "[1377] TlugProcessing 2.0.1" is now approved Link: http://plugins.qgis.org/plugins/TlugProcessing/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [788] Space Syntax Toolkit approval notification.
Plugin Space Syntax Toolkit approval by pcav. The plugin version "[788] Space Syntax Toolkit 0.2.1" is now approved Link: http://plugins.qgis.org/plugins/esstoolkit/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [1391] Asistente LADM_COL approval notification.
Plugin Asistente LADM_COL approval by pcav. The plugin version "[1391] Asistente LADM_COL 0.7.1 Experimental" is now approved Link: http://plugins.qgis.org/plugins/asistente_ladm_col/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] [PyQt] Multiple inheritance from custom widgets and uic
Hi Alexander,
(forwarding to qgis-dev list, as I think it should be also referenced there)
Here is the reply I got from Phil:
> I can confirm it is a bug, however the fix is non-trivial so it won't get
fixed quickly. The fundamental problem is that the code has the assumption
that all custom widgets will reside in the PyQt5 package hard-coded (but
even then it's not quite as simple as that).
He also wrote it's on his todo list in the next 3-4 weeks on that time, but
I don't think it has been solved.
Best wishes,
Denis
Le jeu. 30 août 2018 à 08:35, Alexander Bruy a
écrit :
> Hi all,
>
> usually I use following code to create a form from the Qt Designer's .ui
> file dynamically
>
> from PyQt5 import uic
> FORM_CLASS, BASE_CLASS = uic.loadUiType('/path/to/ui/file.ui')
>
> class MyDialog(BASE_CLASS, FORM_CLASS):
> def __init__(self, parent=None):
> super(MyDialog, self).__init__(parent)
> self.setupUi(self)
>
> and everything works fine.
>
> But seems this approach seems does not work with multiple inheritance.
> There is a custom dialog class (QDialog subclass with custom UI and some
> logic) available in the API library. I want to subclass this custom dialog
> and also apply my own UI to it. I tried following code
>
> from PyQt5 import uic
> from api.ui import CustomDialogBase
>
> FORM_CLASS, BASE_CLASS = uic.loadUiType('/path/to/ui/file.ui')
>
> class MyDialog(BASE_CLASS, CustomDialogBase, FORM_CLASS):
> def __init__(self, parent=None):
> super(MyDialog, self).__init__(parent)
> self.setupUi(self)
>
> But this raises type error
>
> TypeError: Cannot create a consistent method resolution order (MRO)
> for bases QDialog, QgsOptionsDialogBase, Ui_OptionsDialog
>
> As I understand, this is because all classes have the same base class
> QDialog.
>
> Also I tried to specify only one parent class — custom dialog, as it is
> already subclassed from QDialog
>
> from PyQt5 import uic
> from api.ui import CustomDialogBase
>
> FORM_CLASS, BASE_CLASS = uic.loadUiType('/path/to/ui/file.ui')
>
> class MyDialog(CustomDialogBase, FORM_CLASS):
> def __init__(self, parent=None):
> super(MyDialog, self).__init__(parent)
> self.setupUi(self)
>
> But this also does not work, with the error
>
> AttributeError: 'MyDialog' object has no attribute 'groupBox'
>
> As I understand, in this case issue is that FORM_CLASS is a QDialog
> subclass,
> not CustomDialogBase's subclass. After some searching I have found this
> thread
> https://riverbankcomputing.com/pipermail/pyqt/2017-October/039647.html.
> Am I right that currently the only way to solve my issue is to construct
> form from the compiled .ui file?
>
> Thanks
>
> --
> Alexander Bruy
> ___
> PyQt mailing listp...@riverbankcomputing.com
> https://www.riverbankcomputing.com/mailman/listinfo/pyqt
--
Denis Rouzaud
de...@opengis.ch
+41 76 370 21 22
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Do we really need experimental and non-experimental plugins?
Hi, Maybe I am late on this discussion. I agree that showing experimental plugins by default and asking our base users to manage updates from experimental to stable versions may not be a simple task, nor a desired one. But what about showing experimental plugins by default when they are new plugin ie, showing ALL NEW plugins, be it stable or experimental? I mean, when you publish a plugin the first time, you may put it in an experimental status so that users test it and help you fix major issues before an official stable release. But as an experimental plugin, the number of potential testers is really limited given that not all plugins devs have a real place to inform users about their plugin (and if nobody knows that your plugin exists, no one would test...). Then when the plugin publishes its first stable version and it's installed, experimental version notification is no more shown, unless the user checked that option. (*no idea of the amount of work this requires*) Btw I can see that there's a PR at https://github.com/qgis/QGIS/pull/7748 that plans to visually mark experimental plugins so testers would adopt it knowledgeably. I think this would also be a way to educate users about the need of testers... Regards, Harrissou Le mar. 28 août 2018 à 08:11, Richard Duivenvoorde a écrit : > On 08/27/2018 10:17 PM, Borys Jurgiel wrote: > > Dnia poniedziałek, 27 sierpnia 2018 06:21:17 CEST Paolo Cavallini pisze: > >> I agree with Nyall. Furthermore, I'm also -1 on showing deprecated > >> plugins. These are mosty useless, sometimes dangerous. I ask to revert > >> the change ASAP. > > > > Don't worry, it's still a PR (and there are no deprecated 3.x plugins > yet ;) > > Richard, do you want to defend this idea or shall we close the ticket? :) > > Mwa, I like simple things, so if people think this is simpler to handle, > then forget my ticket :-) > > Richard > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Disappearing -180 / 180 longitude grid lines on certain zoom levels
Not sure if it is related, but aren't these actually dateline related issues? Would be cool to tackle the whole dateline issue too :-) Maybe these are related (and having some test cases): https://issues.qgis.org/issues/13380 https://issues.qgis.org/issues/19626 https://issues.qgis.org/issues/597 In the latter there is a link to the grass 'solution'. I had a short look into it, my feeling was that you use 'virtual' worlds on both sides of the dateline to be able to paint the right lines. If you then show them (like googlemaps does when you zoom out a lot), OR cut them out to only show one world is up to you. Though I'm not sure how to cut out a not rectangulare projection easy :-) Regards, Richard Duivenvoorde On 08/29/2018 09:58 PM, Even Rouault wrote: > On mercredi 29 août 2018 21:50:25 CEST Andreas Neumann wrote: >> Hi Even, >> >> Thank you very much for the detailed analysis of the spatial filter >> issue we have here, that causes the disappearing grid lines. >> >> Would you be interested to work on fixing this issue on our bug fixing >> program? This problem annoyed me for quite some time. And it appears on >> different world projections. > > I might have a look at this, if nobody else more familiar with the relevant > code looks at it. Is there a ticket filed about that ? > > Even > >> >> Thanks, >> >> Andreas >> >> Am 28.08.2018 um 22:19 schrieb Even Rouault: >>> Yes, seems restricted to reprojection cases >>> >>> This seems to be an issue with the spatial filter issued to OGR >>> >>> At the zooms where the lines disappear, there are requests like: >>> >>> Thread 23 "Thread (pooled)" hit Breakpoint 2, OGR_L_SetSpatialFilterRect >>> (hLayer=0x7f81180c90a0, dfMinX=-179.79163612932865, >>> dfMinY=-69.446164378986353, dfMaxX=179.90530755284408, >>> dfMaxY=78.959077253477474) at ogrlayer.cpp:1223 >>> >>> At the zooms where that work (even when zoomed in), there are like: >>> >>> Thread 29 "Thread (pooled)" hit Breakpoint 2, OGR_L_SetSpatialFilterRect >>> (hLayer=0x7f81180c90a0, dfMinX=-180, dfMinY=-90, dfMaxX=180, dfMaxY=90) at >>> ogrlayer.cpp:1223 >>> >>> >>> I haven't looked at the QGIS code that computes this bounding box, but >>> from my experience with gdalwarp which has similar challenges, it is >>> tricky to compute a source bounding box from a target bounding box, >>> because sometimes the coordinates in the target bounding box do not >>> correspond to a physical point on Eath, and hence inverse projection >>> fails. So you have to resort to a grid sampling approach, but that makes >>> you miss the exact boundaries. So probably that a band-aid fix would be >>> to add some ad-hoc logic, like "if the source SRS is long/lat, and the >>> computed extent is almost worldwide, then extend it to full worlwide (or >>> do not emit a spatial filter at all)" >>> >>> Even >>> With EPSG:4326 it does not seem to happen, but I tried EPSG:3857 and the -180,180 grid lines do appear and disappear at different zoom levels. I also confirm this with the Robinson projection with the addition that the -90, 90 degree latitude lines also appear and disappear. Calvin On Tue, Aug 28, 2018 at 3:31 PM, Andreas Neumann wrote: > Hi again, > > For some time already I noticed that, depending on the zoom level, the > -180 / 180 degree grid lines appear / disappear in QGIS. This is > unrelated > to the EqualEarth projection just discussed and also appears on other > world > projections, like the Robinson projection. > > Here is the testfile I used with world (countries) and gridlines: > http://www.carto.net/neumann/temp/gridlines.gpkg > > Can you reproduce this behaviour? > > Any idea why this happens and how this could be fixed? > > Thanks, > > Andreas > > > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
