[QGIS-Developer] Making QgsRasterLayerProperties class independent again from QgisApp instance

[Vincent Cloarec]

Hello QGis devs,

I purposed two weeks ago this PR <https://github.com/qgis/QGIS/pull/31942>which
is today marked as "stale".
This PR aims to make the very convenient QgsRasterLayerProperties class
independent from the QgisApp instance. To make this independence stable, I
had followed the Nyall's advice and move the QgsRasterLayerProperties to
the GUI library. I don't know if everything has been made in the rules of
art, but it seems to work.

I want to make this QgsRasterLayerProperties class independent from the
QGisApp to return in the state before the 3.8 version, where the dependency
was created.

I don't think crowd is concerned in this PR  and it not  a big step for
QGIS. I understand QGis devs don't see the advantage of this change.

But, as I am developing stand-alone applications based on the QGis API, I
need to keep the independency from the QGisApp class. Because I don't need
this enormous class and I don't want to have to manage it. On the other
hand, the QgsRasterLayerProperties class is not complicated to use and is
very convenient for displaying the raster layers. Today, I don't imagine
stopping using it!

The purposed PR permits to use this class through the GUI library. This is
cleaner and less tricky than using it from the App library. I think it is a
good thing for stand-alone applications devs.

I don't know if there is a lot of devs who are developing stand-alone
applications. So maybe there is no advantage to accept my PR, and I will
understand it could not be accepted.

But, today,  I need to know if I can count on this PR will be accepted, or
if I have to think about another solution to continue to use the
QgsRasterLayerProperties.

If someone has an idea about this?

Thanks.

Vincent Cloarec
www.reos.site


Le lun. 23 sept. 2019 à 00:25, Vincent Cloarec <vcloarec at gmail.com> a
écrit :

> Hello,
>
> Thanks Nyall for your advice.
>
> I have chosen to move the raster layer properties to the gui. As the
> widget is very convenient, no reason to rebuild my own. Moreover, it
> appears there is not a lot of code to change.
> So I purpose this PR: https://github.com/qgis/QGIS/pull/31942
> The tests seem to pass for QGIS, and I have tried to import the
> QgsRasterLayerProperties class to a standalone application only using the
> gui library, it is ok.
>
> Vincent Cloarec
> www.reos.site
>
>
> Le jeu. 19 sept. 2019 à 00:37, Nyall Dawson <nyall.dawson at gmail.com> a
> écrit :
>
>> On Thu, 19 Sep 2019 at 13:55, Vincent Cloarec <vcloarec at gmail.com> wrote:
>> >
>> > In standalone applications, I am using the QgsRasterLayerProperties
>> class to manage rasters displayed in the map canvas.
>> >
>> > However, since QGis 3.8, this class is no longer independent from the
>> QgisApp instance because the methode
>> QgisApp::instance()->askUserForDatumTransform() is called from the
>> QgsRasterLayerProperties instance.
>> >
>> > As in my standalone applications, I don't have QgsApp instance (no
>> need), now this applications crash when the raster layer properties widget
>> opens ...
>> >
>> > So, after a look at the Qgis code, I am thinking about to make a PR to
>> make again the QgsRasterLayerProperties independant from the QgisApp
>> instance. I think it could be possible with a static method in the QgisApp
>> class. I have to work on it.
>>
>> Possibly -- but it's a band-aid solution only. There's a LOT of code
>> in the app library which will make assumptions that the QgisApp
>> instance is available, and that's why all this code is partitioned off
>> into the app library. app also has no stable API guarantees and you'll
>> continue to hit situations like this.
>>
>> I'd suggest two possible alternative ways forward:
>>
>> 1. Use the stable api classes exposes through the gui library to
>> rebuild your own raster layer properties dialog
>> 2. Submit a PR moving the raster layer properties class from app ->
>> gui and adding it to the stable API
>>
>> Both approaches are more upfront work, but are paths to much less pain
>> and future breakage...
>>
>> Nyall
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20191007/3341ce04/attachment.html>