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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Vincent Cloarec
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.

But before trying this solution, I would have your opinion if it makes sens to go in this way.

Thanks.

Vincent Cloarec


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Nyall Dawson
On Thu, 19 Sep 2019 at 13:55, Vincent Cloarec <[hidden email]> 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
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Vincent Cloarec
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.
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


Le jeu. 19 sept. 2019 à 00:37, Nyall Dawson <[hidden email]> a écrit :
On Thu, 19 Sep 2019 at 13:55, Vincent Cloarec <[hidden email]> 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

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Vincent Cloarec
Hello,

I have some difficulties in passing the Travis tests with this PR: https://github.com/qgis/QGIS/pull/31942.

As I am fed up to make turning the server for nothing and reject CO2, I ask for help.

The 'code layout' tests seem not to pass. Reading the log, I can find this link http://tinyurl.com/yynt7m9a. Following this link, it seems the problems come from warning: undocumented parameters and unknown command '\TODO'.

Can anyone confirm ?

Thanks.

Vincent Cloarec


Le lun. 23 sept. 2019 à 00:25, Vincent Cloarec <[hidden email]> 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.
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


Le jeu. 19 sept. 2019 à 00:37, Nyall Dawson <[hidden email]> a écrit :
On Thu, 19 Sep 2019 at 13:55, Vincent Cloarec <[hidden email]> 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

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Alessandro Pasotti-2

On Mon, Sep 23, 2019 at 6:15 PM Vincent Cloarec <[hidden email]> wrote:
Hello,

I have some difficulties in passing the Travis tests with this PR: https://github.com/qgis/QGIS/pull/31942.

As I am fed up to make turning the server for nothing and reject CO2, I ask for help.

The 'code layout' tests seem not to pass. Reading the log, I can find this link http://tinyurl.com/yynt7m9a. Following this link, it seems the problems come from warning: undocumented parameters and unknown command '\TODO'.

Can anyone confirm ?

Confirmed.

You need to complete the documentation of a few methods.
I don't know where the TODO comes from though.



Thanks.

Vincent Cloarec


Le lun. 23 sept. 2019 à 00:25, Vincent Cloarec <[hidden email]> 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.
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


Le jeu. 19 sept. 2019 à 00:37, Nyall Dawson <[hidden email]> a écrit :
On Thu, 19 Sep 2019 at 13:55, Vincent Cloarec <[hidden email]> 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
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


--
Alessandro Pasotti
w3:   www.itopen.it

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Vincent Cloarec

Le lun. 23 sept. 2019 à 12:24, Alessandro Pasotti <[hidden email]> a écrit :

On Mon, Sep 23, 2019 at 6:15 PM Vincent Cloarec <[hidden email]> wrote:
Hello,

I have some difficulties in passing the Travis tests with this PR: https://github.com/qgis/QGIS/pull/31942.

As I am fed up to make turning the server for nothing and reject CO2, I ask for help.

The 'code layout' tests seem not to pass. Reading the log, I can find this link http://tinyurl.com/yynt7m9a. Following this link, it seems the problems come from warning: undocumented parameters and unknown command '\TODO'.

Can anyone confirm ?

Confirmed.

You need to complete the documentation of a few methods.
I don't know where the TODO comes from though.



Thanks.

Vincent Cloarec


Le lun. 23 sept. 2019 à 00:25, Vincent Cloarec <[hidden email]> 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.
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


Le jeu. 19 sept. 2019 à 00:37, Nyall Dawson <[hidden email]> a écrit :
On Thu, 19 Sep 2019 at 13:55, Vincent Cloarec <[hidden email]> 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
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


--
Alessandro Pasotti
w3:   www.itopen.it

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Vincent Cloarec
In reply to this post by Alessandro Pasotti-2
OK, thanks, the tests has passed now.

As you say, that was the undocumented parameters.

And '///@TODO' code in the ccp file that was making the warning and failing the test.


Le lun. 23 sept. 2019 à 12:24, Alessandro Pasotti <[hidden email]> a écrit :

On Mon, Sep 23, 2019 at 6:15 PM Vincent Cloarec <[hidden email]> wrote:
Hello,

I have some difficulties in passing the Travis tests with this PR: https://github.com/qgis/QGIS/pull/31942.

As I am fed up to make turning the server for nothing and reject CO2, I ask for help.

The 'code layout' tests seem not to pass. Reading the log, I can find this link http://tinyurl.com/yynt7m9a. Following this link, it seems the problems come from warning: undocumented parameters and unknown command '\TODO'.

Can anyone confirm ?

Confirmed.

You need to complete the documentation of a few methods.
I don't know where the TODO comes from though.



Thanks.

Vincent Cloarec


Le lun. 23 sept. 2019 à 00:25, Vincent Cloarec <[hidden email]> 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.
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


Le jeu. 19 sept. 2019 à 00:37, Nyall Dawson <[hidden email]> a écrit :
On Thu, 19 Sep 2019 at 13:55, Vincent Cloarec <[hidden email]> 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
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


--
Alessandro Pasotti
w3:   www.itopen.it

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Vincent Cloarec
In reply to this post by Vincent Cloarec
Hello QGis devs,

I purposed two weeks ago this PR 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


Le lun. 23 sept. 2019 à 00:25, Vincent Cloarec <[hidden email]> 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.
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


Le jeu. 19 sept. 2019 à 00:37, Nyall Dawson <[hidden email]> a écrit :
On Thu, 19 Sep 2019 at 13:55, Vincent Cloarec <[hidden email]> 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

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

pcav
Hi all,

On 07/10/19 22:05, Vincent Cloarec wrote:
...

> 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?

this seems reasonable to me, as generally keeping the GUI separated is a
good practice.
Anyone sees a problem here?
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Peter Petrik
Hi Vincent, 

we are now in the feature freeze period, so I am not sure if this change would not fall to QGIS 3.12 life cycle beginning at the end of October. We are kind of busy at the moment doing bugfixes and pre-release changes. Hopefully after the release is sorted there would be more drive for review and merge of such infrastructure changes.

Cheers, 
Peter 



On Tue, Oct 8, 2019 at 7:13 AM Paolo Cavallini <[hidden email]> wrote:
Hi all,

On 07/10/19 22:05, Vincent Cloarec wrote:
...
> 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?

this seems reasonable to me, as generally keeping the GUI separated is a
good practice.
Anyone sees a problem here?
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Tim Sutton-6
Also I believe PR’s are automatically marked as old after two weeks by a little helper bot - so it is not a personal thing. I think you can keep it from going stale by popping in and updating it regularly so devs know you still care about it, then as Peter suggests wait for post-freeze.

Regards

Tim

On 8 Oct 2019, at 07:21, Peter Petrik <[hidden email]> wrote:

Hi Vincent, 

we are now in the feature freeze period, so I am not sure if this change would not fall to QGIS 3.12 life cycle beginning at the end of October. We are kind of busy at the moment doing bugfixes and pre-release changes. Hopefully after the release is sorted there would be more drive for review and merge of such infrastructure changes.

Cheers, 
Peter 



On Tue, Oct 8, 2019 at 7:13 AM Paolo Cavallini <[hidden email]> wrote:
Hi all,

On 07/10/19 22:05, Vincent Cloarec wrote:
...
> 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?

this seems reasonable to me, as generally keeping the GUI separated is a
good practice.
Anyone sees a problem here?
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link to make finding time easy.


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Making QgsRasterLayerProperties class independent again from QgisApp instance

Vincent Cloarec
Thanks for this information.

No problem if this PR is merged (or not) after october, I will wait.

Good luck for this freeze period!

Le mar. 8 oct. 2019 à 04:13, Tim Sutton <[hidden email]> a écrit :
Also I believe PR’s are automatically marked as old after two weeks by a little helper bot - so it is not a personal thing. I think you can keep it from going stale by popping in and updating it regularly so devs know you still care about it, then as Peter suggests wait for post-freeze.

Regards

Tim

On 8 Oct 2019, at 07:21, Peter Petrik <[hidden email]> wrote:

Hi Vincent, 

we are now in the feature freeze period, so I am not sure if this change would not fall to QGIS 3.12 life cycle beginning at the end of October. We are kind of busy at the moment doing bugfixes and pre-release changes. Hopefully after the release is sorted there would be more drive for review and merge of such infrastructure changes.

Cheers, 
Peter 



On Tue, Oct 8, 2019 at 7:13 AM Paolo Cavallini <[hidden email]> wrote:
Hi all,

On 07/10/19 22:05, Vincent Cloarec wrote:
...
> 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?

this seems reasonable to me, as generally keeping the GUI separated is a
good practice.
Anyone sees a problem here?
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link to make finding time easy.

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer