- changed version to 3.9
when applying changes in the Raster Band tab of the Layer Properties, the sliders reset to their initial state
This bug only appears in QGIS. In the EnMAP-Box it works fine.
Comments (38)
-
reporter -
- changed status to on hold
referese to https://github.com/qgis/QGIS/issues/34602
-
reporter Not sure if we should set known bugs on hold. Maybe you are right, bugs that we can not solve right now, can be on hold.
-
reporter As this is only happening in QGIS, a good workaround is to use the Layer Styling, this is working as expected:
-
reporter The bug is now also affecting the EnMAP-Box and not only QGIS. This Raster Band widget is now quit useless. It also looks like QGIS communitity isn’t concidering it as a Bug anymore and closed the issue:
-
reporter Benjamin, can’t we really do nothing about it? Can’t you just directly update the renderer of the layer, when the user interacts with any of those widgets:
So the user selects the bands and just leaves the dialog by clicking on Ok and not on Apply first (which would reset the selection).
Yes, it’s a suboptimal workaround, but at least the dialog would be useful.
-
reporter - changed status to open
-
The widget works well in the layer styling widget, so I would’nt consider it “quite useless” at all.
-
Anyway, seems the QGIS API has changed somehow. Needs more time to figure out why the expected band changes are not written to the raster layer.
-
reporter The widget works well in the layer styling widget, so I would’nt consider it “quite useless” at all.
Yes, but note that the EnMAP-Box currently has no Layer Styling panel. The workaround I mentioned on 2021-09-24 is only available outside of the EnMAP-Box, when working in the QGIS main window.
Also, the workaround is not really practical, because layers in QGIS and in the EnMAP-Box are not “shared” between each other. For example, I couldn’t easily use the QGIS Layer Styling panel to select spectral bands for the enmap_berlin.bsq layer opened in the EnMAP-Box.
-
reporter Benjamin, is this bug related to the bug in your BitFlagRenderer plugin?: https://bitbucket.org/jakimowb/bit-flag-renderer/issues/14/bitflagrenderer-is-broken-in-qgis-320
If so, maybe you can just directly update the renderer (like you do in the BitFlagRanderer), when the user is interacting with any of the buttons. And instead of closing the dialog via the Ok button, we use the same workaround as in the BitFlagRenderer issue and just use the Cancel button to close the dialog.
Could that work?
-
reporter - changed milestone to 3.9 (Hotfix)
-
- changed status to closed
-
reporter Sorry, but I can’t confirm that this is working now.
I also get an error in the console:
Traceback (most recent call last): File "D:\source\QGISPlugIns\enmap-box\enmapbox\qgispluginsupport\qps\layerconfigwidgets\rasterbands.py", line 252, in syncToLayer renderer = self.mLayer.renderer().clone() AttributeError: 'NoneType' object has no attribute 'clone'
-
reporter - changed status to open
-
You are right. There is still a problem in the QgsRasterLayerProperties dialog.
-
- changed status to resolved
refactoring resolves
#689(requires submodule to pull in https://github.com/EnMAP-Box/qgispluginsupport/commit/7b981ca6c496a4c5a2ecca22f8fb6438817a840c)→ <<cset 9b621b60da1e>>
-
- changed status to open
-
- changed status to resolved
updates submodules create_plugin.py: -z skips zipfile, -p considers EMB_DEPLOY_PROFILE to install plugin to QGIS profile folder added flake8u.sh to run flake8 for uncommitted files only resolves
#689for QGIS 3.22+ (required qps submodule update)→ <<cset 6fe11abc73a1>>
-
reporter I still get the error message from above.
Traceback (most recent call last): File "D:\source\QGISPlugIns\enmap-box\enmapbox\qgispluginsupport\qps\layerconfigwidgets\rasterbands.py", line 252, in syncToLayer renderer = self.mLayer.renderer().clone() AttributeError: 'NoneType' object has no attribute 'clone'
And when opening the Layer Properties again, Python crashes:
Traceback (most recent call last): File "D:\source\QGISPlugIns\enmap-box\enmapbox\qgispluginsupport\qps\layerconfigwidgets\rasterbands.py", line 252, in syncToLayer renderer = self.mLayer.renderer().clone() AttributeError: 'NoneType' object has no attribute 'clone' Traceback (most recent call last): File "D:\source\QGISPlugIns\enmap-box\enmapbox\qgispluginsupport\qps\layerconfigwidgets\rasterbands.py", line 415, in createWidget w = RasterBandConfigWidget(layer, canvas, parent=parent) File "D:\source\QGISPlugIns\enmap-box\enmapbox\qgispluginsupport\qps\layerconfigwidgets\rasterbands.py", line 239, in __init__ self.syncToLayer() File "D:\source\QGISPlugIns\enmap-box\enmapbox\qgispluginsupport\qps\layerconfigwidgets\rasterbands.py", line 252, in syncToLayer renderer = self.mLayer.renderer().clone() AttributeError: 'NoneType' object has no attribute 'clone' Process finished with exit code -1073741819 (0xC0000005)
-
reporter - changed status to open
-
Can you described the steps to reproduce this error?
-
reporter Just by using it:
-
Can't reproduce this neither for QGIS 3.22, nor for 3.24.
Actually the RasterBandConfigWidget should’nt show up in 3.22 at all, so you are likely working with outdatet submodules. -
reporter Hmm, strange, Git says I’m up to date:
-
reporter Can’t trust those submoduls
-
Which branch & commit are they following? In both cases it should be the latest commit in the origin master:
$ git submodule +f7deeb9f30bf65eb25984f99b62e6036b9b0cee7 enmapbox/apps/lmuapps (heads/master) +fbf6b5ab8561398630ef85828a9094bc24fe4c86 enmapbox/qgispluginsupport (heads/master)
$ git submodule foreach git pull Entering 'enmapbox/apps/lmuapps' Already up to date. Entering 'enmapbox/qgispluginsupport' Already up to date.
-
In your case, does running git pull in the EnMAP-Box repo also pull updates from the submodules?
$ git pull Fetching submodule enmapbox/apps/lmuapps Fetching submodule enmapbox/qgispluginsupport Already up to date.
-
reporter Oh oh, this looks different than yours:
How can I fix this?
-
Go into the submodules directory and checkout the origins' master
-
reporter Please give exact command.
-
here it is https://stackoverflow.com/a/5828396
-
reporter Ok, now it looks good.
So the problem was the wrong branch, right?
From now on, I just need to pull the main repo, right?
-
@Andreas Janz please close this issue if you managed to pull the submodules accordingly
-
reporter For now it looks good.
What about my questions?
-
Yes, as usuall you just didn’t checkout the latests updates
-
- changed status to closed
-
reporter Yes, as usuall you just didn’t checkout the latests updates
You mean the dumb submodules didn’t work properly again
- Log in to comment