[QGIS-Developer] how compatible .qml files are ?

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

[QGIS-Developer] how compatible .qml files are ?

Sandro Santilli-4
I just filed https://github.com/qgis/QGIS/issues/31471 after finding
out that a .qml file created with QGIS 1.9.0 is not fully honoured
with curretn QGIS master (and I think 3.4.0 as well).

Yes, I know 1.9.0 is old but... is this level of backward
compatibility supposed to work ? Or are there tools to convert
saved styles across versions ?

--strk;
_______________________________________________
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: how compatible .qml files are ?

pcav
Hi Sandro,

On 28/08/19 17:43, Sandro Santilli wrote:
> I just filed https://github.com/qgis/QGIS/issues/31471 after finding
> out that a .qml file created with QGIS 1.9.0 is not fully honoured
> with curretn QGIS master (and I think 3.4.0 as well).
>
> Yes, I know 1.9.0 is old but... is this level of backward
> compatibility supposed to work ? Or are there tools to convert
> saved styles across versions ?

my understanding is that maintaining compatibility is just too hard to
achieve, and we never promised to our users.
What I always recommend in training and support is to convert projects
from one version to the next, as this should be mostly handled correctly.
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: how compatible .qml files are ?

Sandro Santilli-4
On Wed, Aug 28, 2019 at 06:42:15PM +0200, Paolo Cavallini wrote:

> Hi Sandro,
>
> On 28/08/19 17:43, Sandro Santilli wrote:
> > I just filed https://github.com/qgis/QGIS/issues/31471 after finding
> > out that a .qml file created with QGIS 1.9.0 is not fully honoured
> > with curretn QGIS master (and I think 3.4.0 as well).
> >
> > Yes, I know 1.9.0 is old but... is this level of backward
> > compatibility supposed to work ? Or are there tools to convert
> > saved styles across versions ?
>
> my understanding is that maintaining compatibility is just too hard to
> achieve, and we never promised to our users.
> What I always recommend in training and support is to convert projects
> from one version to the next, as this should be mostly handled correctly.

How are them converted ? And note we're talking about styles, not full
projects here. And styles that are shipped with QGIS itself (could
this be automated, for shipped styles?).

--strk;
_______________________________________________
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: how compatible .qml files are ?

Nyall Dawson
In reply to this post by pcav
On Thu, 29 Aug 2019 at 02:44, Paolo Cavallini <[hidden email]> wrote:

>
> Hi Sandro,
>
> On 28/08/19 17:43, Sandro Santilli wrote:
> > I just filed https://github.com/qgis/QGIS/issues/31471 after finding
> > out that a .qml file created with QGIS 1.9.0 is not fully honoured
> > with curretn QGIS master (and I think 3.4.0 as well).
> >
> > Yes, I know 1.9.0 is old but... is this level of backward
> > compatibility supposed to work ? Or are there tools to convert
> > saved styles across versions ?
>
> my understanding is that maintaining compatibility is just too hard to
> achieve, and we never promised to our users.

Yep - 1.9 to 3.x is a HUGE jump, especially if the project was first
created in an even earlier version (my timeline is shaky here, but it
likely could even be using symbology v1. ouch!). All this old 1.x
compatiblity code was dropped in the 2 -> 3 migration, with the
recommendation being that users who need to open a 1.x project first
load and resave it in 2.18.

> How are them converted ?

See above -- open in 2.18, save, open in 3.x, save.

> And note we're talking about styles, not full projects here. And styles that are shipped with QGIS itself (could this be automated, for shipped styles?).

I don't think it's worth the effort of automating a transition to be
honest. This situation occurs so infrequently (once in the past 10
years) that it's unlikely to pay off. If you want to ensure the style
is future proof, then I'd suggest building it dynamically when
required, and doing it in c++. Then it's effectively guaranteed to
keep working and if anyone changes API, they'll need to fix your code
in order to build....

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: how compatible .qml files are ?

Sandro Santilli-4
On Thu, Aug 29, 2019 at 08:41:03AM +1000, Nyall Dawson wrote:
> On Thu, 29 Aug 2019 at 02:44, Paolo Cavallini <[hidden email]> wrote:
> > On 28/08/19 17:43, Sandro Santilli wrote:
> > > I just filed https://github.com/qgis/QGIS/issues/31471 after finding
>
> All this old 1.x
> compatiblity code was dropped in the 2 -> 3 migration, with the

Ouch, destructive move.

> recommendation being that users who need to open a 1.x project first
> load and resave it in 2.18.

Will try that. Then I guess I'll have to update DBManager templates
in all supported branches: 3.4, 3.8, master -- correct ?

> I don't think it's worth the effort of automating a transition to be
> honest. This situation occurs so infrequently (once in the past 10
> years) that it's unlikely to pay off. If you want to ensure the style
> is future proof, then I'd suggest building it dynamically when
> required, and doing it in c++. Then it's effectively guaranteed to
> keep working and if anyone changes API, they'll need to fix your code
> in order to build....

So not even python is API safe ?
Remember we're talking about a core plugin here.

Do you have examples of building style dynamically ?

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   https://strk.kbt.io/services.html
_______________________________________________
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: how compatible .qml files are ?

Matthias Kuhn 🌍
On 8/29/19 10:43 AM, Sandro Santilli wrote:
>> recommendation being that users who need to open a 1.x project first
>> load and resave it in 2.18.
> Will try that. Then I guess I'll have to update DBManager templates
> in all supported branches: 3.4, 3.8, master -- correct ?

You can do it on master only and add backport labels which will trigger
the backports if there are no conflicts.

>> I don't think it's worth the effort of automating a transition to be
>> honest. This situation occurs so infrequently (once in the past 10
>> years) that it's unlikely to pay off. If you want to ensure the style
>> is future proof, then I'd suggest building it dynamically when
>> required, and doing it in c++. Then it's effectively guaranteed to
>> keep working and if anyone changes API, they'll need to fix your code
>> in order to build....
> So not even python is API safe ?

It is stable throughout version 3.

Longer term, with C++ it's more likely that breaks are noticed just in
time, because the compiler is quite good at detecting incompatible api
changes.

> Do you have examples of building style dynamically ?

Something like this
https://github.com/qgis/QGIS/blob/master/tests/src/python/test_qgscategorizedsymbolrenderer.py 
?

Matthias

>
> --strk;
>
>    ()   Free GIS & Flash consultant/developer
>    /\   https://strk.kbt.io/services.html
> _______________________________________________
> 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: how compatible .qml files are ?

Nyall Dawson
In reply to this post by Sandro Santilli-4
On Thu, 29 Aug 2019 at 18:44, Sandro Santilli <[hidden email]> wrote:

>
> On Thu, Aug 29, 2019 at 08:41:03AM +1000, Nyall Dawson wrote:
> > On Thu, 29 Aug 2019 at 02:44, Paolo Cavallini <[hidden email]> wrote:
> > > On 28/08/19 17:43, Sandro Santilli wrote:
> > > > I just filed https://github.com/qgis/QGIS/issues/31471 after finding
> >
> > All this old 1.x
> > compatiblity code was dropped in the 2 -> 3 migration, with the
>
> Ouch, destructive move.

No, not at all. And honestly, I'm surprised to hear this attitude from
you. You'd know full well that the opensource community is a finite
resource.

It was the right move to drop this unused legacy code rather than
waste the valuable maintainer power on something completely unused.

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: how compatible .qml files are ?

Sandro Santilli-4
On Thu, Aug 29, 2019 at 08:05:04PM +1000, Nyall Dawson wrote:

> On Thu, 29 Aug 2019 at 18:44, Sandro Santilli <[hidden email]> wrote:
> >
> > On Thu, Aug 29, 2019 at 08:41:03AM +1000, Nyall Dawson wrote:
> > > On Thu, 29 Aug 2019 at 02:44, Paolo Cavallini <[hidden email]> wrote:
> > > > On 28/08/19 17:43, Sandro Santilli wrote:
> > > > > I just filed https://github.com/qgis/QGIS/issues/31471 after finding
> > >
> > > All this old 1.x
> > > compatiblity code was dropped in the 2 -> 3 migration, with the
> >
> > Ouch, destructive move.
>
> No, not at all. And honestly, I'm surprised to hear this attitude from
> you. You'd know full well that the opensource community is a finite
> resource.
>
> It was the right move to drop this unused legacy code rather than
> waste the valuable maintainer power on something completely unused.

It could have been moved to a convertion tool.

Yes I know time is a finite resource, just think about all the time
that has to be spent to convert project/style files ! As I'm writing
this I'm converting the 11 (11!) style files that are shipped with
QGIS itself and are incompatible (since 3.0, is my take?).

Are style files versioned ? It could help to do that, moving forward.
At least QGIS could warn user/error out when trying to open a file
older than 3.0, and give the hint about using 2.18 to convert them.

--strk;
_______________________________________________
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: how compatible .qml files are ?

Nyall Dawson
On Thu, 29 Aug 2019 at 20:29, Sandro Santilli <[hidden email]> wrote:

>
> On Thu, Aug 29, 2019 at 08:05:04PM +1000, Nyall Dawson wrote:
> > On Thu, 29 Aug 2019 at 18:44, Sandro Santilli <[hidden email]> wrote:
> > >
> > > On Thu, Aug 29, 2019 at 08:41:03AM +1000, Nyall Dawson wrote:
> > > > On Thu, 29 Aug 2019 at 02:44, Paolo Cavallini <[hidden email]> wrote:
> > > > > On 28/08/19 17:43, Sandro Santilli wrote:
> > > > > > I just filed https://github.com/qgis/QGIS/issues/31471 after finding
> > > >
> > > > All this old 1.x
> > > > compatiblity code was dropped in the 2 -> 3 migration, with the
> > >
> > > Ouch, destructive move.
> >
> > No, not at all. And honestly, I'm surprised to hear this attitude from
> > you. You'd know full well that the opensource community is a finite
> > resource.
> >
> > It was the right move to drop this unused legacy code rather than
> > waste the valuable maintainer power on something completely unused.
>
> It could have been moved to a convertion tool.

There was no volunteers to do this, and no sponsorship for work of
this nature => no conversion tool. ;)

> Are style files versioned ?

Yes

> It could help to do that, moving forward.
> At least QGIS could warn user/error out when trying to open a file
> older than 3.0, and give the hint about using 2.18 to convert them.

That's a good idea -- can you submit a PR?

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: how compatible .qml files are ?

Sandro Santilli-4
In reply to this post by Matthias Kuhn 🌍
On Thu, Aug 29, 2019 at 11:39:23AM +0200, Matthias Kuhn wrote:
> On 8/29/19 10:43 AM, Sandro Santilli wrote:
> > > recommendation being that users who need to open a 1.x project first
> > > load and resave it in 2.18.
> > Will try that. Then I guess I'll have to update DBManager templates
> > in all supported branches: 3.4, 3.8, master -- correct ?
>
> You can do it on master only and add backport labels which will trigger the
> backports if there are no conflicts.

I've filed the PR and added backport labels:

  https://github.com/qgis/QGIS/pull/31490

Do backport happen automatically after merge or is there anything else
I should do before proceeding ?

--strk;
_______________________________________________
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: how compatible .qml files are ?

Sandro Santilli-4
In reply to this post by Nyall Dawson
On Thu, Aug 29, 2019 at 08:35:09PM +1000, Nyall Dawson wrote:

> On Thu, 29 Aug 2019 at 20:29, Sandro Santilli <[hidden email]> wrote:
> > On Thu, Aug 29, 2019 at 08:05:04PM +1000, Nyall Dawson wrote:
> > >
> > > It was the right move to drop this unused legacy code rather than
> > > waste the valuable maintainer power on something completely unused.
> >
> > It could have been moved to a convertion tool.
>
> There was no volunteers to do this, and no sponsorship for work of
> this nature => no conversion tool. ;)

I'd think whoever introduced the _new_ format should have taken
care of providing an upgrade path for those with an old format.

Do you know which commit dropped the backward compatibility, exactly ?
Note that "something completely unused" (just re-reading your quoted
text) was actually still used by QGIS itself...

> > At least QGIS could warn user/error out when trying to open a file
> > older than 3.0, and give the hint about using 2.18 to convert them.
>
> That's a good idea -- can you submit a PR?

I could try. My first exploration brought me in
src/core/qgsmaplayer.cpp, in this block:

  // get style file version string, if any
  QgsProjectVersion fileVersion( myRoot.attribute( QStringLiteral( "version" ) ) );
  QgsProjectVersion thisVersion( Qgis::QGIS_VERSION );

  if ( thisVersion > fileVersion )
  {
    QgsProjectFileTransform styleFile( myDocument, fileVersion );
    styleFile.updateRevision( thisVersion );
  }

It would sound like QgsProjectFileTransform::updateRevision should throw
an exception when unable to do what's been asked for ?

--strk;
_______________________________________________
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: how compatible .qml files are ?

Sandro Santilli-4
In reply to this post by Nyall Dawson
On Thu, Aug 29, 2019 at 08:41:03AM +1000, Nyall Dawson wrote:

> All this old 1.x compatiblity code was dropped in the 2 -> 3 migration

Do you have any reference of the exact commit which removed such
compatibility ?

This does not give me any hint:

  git log --stat src/core/qgsprojectfiletransform.cpp

Also, the methods of that class suggest there is conversion code
for versions as old as 0.8.0:

        QgsProjectFileTransform::TransformItem QgsProjectFileTransform::sTransformers[] =
        {
                {PFV( 0, 8, 0 ), PFV( 0, 8, 1 ), &QgsProjectFileTransform::transformNull},
                {PFV( 0, 8, 1 ), PFV( 0, 9, 0 ), &QgsProjectFileTransform::transform081to090},
                {PFV( 0, 9, 0 ), PFV( 0, 9, 1 ), &QgsProjectFileTransform::transformNull},
                {PFV( 0, 9, 1 ), PFV( 0, 10, 0 ), &QgsProjectFileTransform::transform091to0100},
                // Following line is a hack that takes us straight from 0.9.2 to 0.11.0
                // due to an unknown bug in migrating 0.9.2 files which we didn't pursue (TS & GS)
                {PFV( 0, 9, 2 ), PFV( 0, 11, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 0, 10, 0 ), PFV( 0, 11, 0 ), &QgsProjectFileTransform::transform0100to0110},
                {PFV( 0, 11, 0 ), PFV( 1, 0, 0 ), &QgsProjectFileTransform::transform0110to1000},
                {PFV( 1, 0, 0 ), PFV( 1, 1, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 1, 0, 2 ), PFV( 1, 1, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 1, 1, 0 ), PFV( 1, 2, 0 ), &QgsProjectFileTransform::transform1100to1200},
                {PFV( 1, 2, 0 ), PFV( 1, 3, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 1, 3, 0 ), PFV( 1, 4, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 1, 4, 0 ), PFV( 1, 5, 0 ), &QgsProjectFileTransform::transform1400to1500},
                {PFV( 1, 5, 0 ), PFV( 1, 6, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 1, 6, 0 ), PFV( 1, 7, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 1, 7, 0 ), PFV( 1, 8, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 1, 8, 0 ), PFV( 1, 9, 0 ), &QgsProjectFileTransform::transform1800to1900},
                {PFV( 1, 9, 0 ), PFV( 2, 0, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 2, 0, 0 ), PFV( 2, 1, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 2, 1, 0 ), PFV( 2, 2, 0 ), &QgsProjectFileTransform::transformNull},
                {PFV( 2, 2, 0 ), PFV( 2, 3, 0 ), &QgsProjectFileTransform::transform2200to2300},
                // A transformer with a NULL from version means that it should be run when upgrading
                // from any version and will take care that it's not going to cause trouble if it's
                // run several times on the same file.
                {PFV(), PFV( 3, 0, 0 ), &QgsProjectFileTransform::transform3000},
        };

--strk;
_______________________________________________
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: how compatible .qml files are ?

Nyall Dawson
In reply to this post by Sandro Santilli-4
On Sat, 31 Aug 2019 at 17:02, Sandro Santilli <[hidden email]> wrote:

>
> On Thu, Aug 29, 2019 at 08:35:09PM +1000, Nyall Dawson wrote:
> > On Thu, 29 Aug 2019 at 20:29, Sandro Santilli <[hidden email]> wrote:
> > > On Thu, Aug 29, 2019 at 08:05:04PM +1000, Nyall Dawson wrote:
> > > >
> > > > It was the right move to drop this unused legacy code rather than
> > > > waste the valuable maintainer power on something completely unused.
> > >
> > > It could have been moved to a convertion tool.
> >
> > There was no volunteers to do this, and no sponsorship for work of
> > this nature => no conversion tool. ;)
>
> I'd think whoever introduced the _new_ format should have taken
> care of providing an upgrade path for those with an old format.

Not necessarily -- this was a wide group decision, with consensus from
all currently active QGIS developers and maintainers. It was deemed
unnecessary at this point in time. I strongly suspect that there's a
cultural or language effect in play here, but it's hard not to
(mis)interpret this thread as disrespecting the decisions made by the
active QGIS developers and community of the time. Just like I wouldn't
dream of jumping onto the GDAL or Qt lists and questioning design
decisions made by people with intimate knowledge of the code base and
wider context and constraints of discussions, I'd ask you to extend
the same respect and courtesy to our community and the individuals who
have made these informed decisions. These decisions were made,
accepted, and implemented -- let's not argue them retrospectively, but
accept and move on instead.

It's GREAT that you're seeking to address what you see as a feature
gap/bug in QGIS, but I just want to caution that your language is
likely mis-representing your intentions here. (Also I hope that my
tone won't be misinterpreted here either! Cross-cultural community
building is HAAAARD :O )

>
> Do you know which commit dropped the backward compatibility, exactly ?
> Note that "something completely unused" (just re-reading your quoted
> text) was actually still used by QGIS itself...

No, no idea sorry. It would have been 2-3 years ago now, and it was a
mass deletion commit, so git blame won't be much use. You may be able
to git blame qgsvectorlayer.cpp or qgsvectorlayerrenderer.cpp to find.

> It would sound like QgsProjectFileTransform::updateRevision should throw
> an exception when unable to do what's been asked for ?

In this case QgsProjectFileTransform will be a red herring - there was
never a transform in place for this code, so there won't be any clues
there.

Nyall

>
> --strk;
_______________________________________________
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: how compatible .qml files are ?

Sandro Santilli-4
On Sun, Sep 01, 2019 at 08:19:18AM +1000, Nyall Dawson wrote:
> On Sat, 31 Aug 2019 at 17:02, Sandro Santilli <[hidden email]> wrote:
> >
> > It would sound like QgsProjectFileTransform::updateRevision should throw
> > an exception when unable to do what's been asked for ?
>
> In this case QgsProjectFileTransform will be a red herring - there was
> never a transform in place for this code, so there won't be any clues
> there.

You mean QgsProjectFileTransform class never dealt with style configured in
project files ? Or what does "for this code" mean, exactly ?

Regarding dropping backward compatibility, you say:

> this was a wide group decision, with consensus from
> all currently active QGIS developers and maintainers. It was deemed
> unnecessary at this point in time.

Do you have a link to a mailing list thread where decision taking
process was conducted ? Just in case it has some hints about how
to fix this backward compatibility problem as QGIS moves forward.

--strk;
_______________________________________________
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: how compatible .qml files are ?

Matthias Kuhn 🌍
On 9/2/19 12:02 PM, Sandro Santilli wrote:
> On Sun, Sep 01, 2019 at 08:19:18AM +1000, Nyall Dawson wrote:
>> On Sat, 31 Aug 2019 at 17:02, Sandro Santilli <[hidden email]> wrote:
>>> It would sound like QgsProjectFileTransform::updateRevision should throw
>>> an exception when unable to do what's been asked for ?
>> In this case QgsProjectFileTransform will be a red herring - there was
>> never a transform in place for this code, so there won't be any clues
>> there.
> You mean QgsProjectFileTransform class never dealt with style configured in
> project files ? Or what does "for this code" mean, exactly ?

Possibly. Sometimes there was/is legacy loading code directly inside the
readXml classes.

If you want to work on it now however, QgsProjectFileTransform sounds
like the path to go.

I reckon it was removed mainly because it cluttered the readXml code in
the classes.

Bests

Matthias

>
> Regarding dropping backward compatibility, you say:
>
>> this was a wide group decision, with consensus from
>> all currently active QGIS developers and maintainers. It was deemed
>> unnecessary at this point in time.
> Do you have a link to a mailing list thread where decision taking
> process was conducted ? Just in case it has some hints about how
> to fix this backward compatibility problem as QGIS moves forward.
>
> --strk;
> _______________________________________________
> 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: how compatible .qml files are ?

Sandro Santilli-4
In reply to this post by Nyall Dawson
On Sun, Sep 01, 2019 at 08:19:18AM +1000, Nyall Dawson wrote:
> On Sat, 31 Aug 2019 at 17:02, Sandro Santilli <[hidden email]> wrote:

> > Do you know which commit dropped the backward compatibility, exactly ?
> > Note that "something completely unused" (just re-reading your quoted
> > text) was actually still used by QGIS itself...
>
> No, no idea sorry. It would have been 2-3 years ago now, and it was a
> mass deletion commit, so git blame won't be much use. You may be able
> to git blame qgsvectorlayer.cpp or qgsvectorlayerrenderer.cpp to find.

Could this be the one?

  commit 8e5fb436b702b9ab3d2112557f57e5a49cdea03a
  Author: Martin Dobias <[hidden email]>
  Date:   Wed Dec 14 09:45:39 2016 +0800

      Remove QgsLabelingEngineInterface base class and implementation in QgsPalLabeling

      It was ready to go for some time, just waiting for QgsMapRender that still used it.

   src/core/qgsvectorlayerrenderer.cpp | 122
  +++++++++++++++++++++++++++++++++----------------------------------------------------------------------
   1 file changed, 39 insertions(+), 83 deletions(-)

Unfortunately `git log --grep compat` doesn't give many hints,
and the NEWS file doesn't have any section of broken backward
compatibility for the 3.0 section either.

--strk;
_______________________________________________
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: how compatible .qml files are ?

Nyall Dawson
On Mon, 2 Sep 2019 at 20:30, Sandro Santilli <[hidden email]> wrote:

>
> On Sun, Sep 01, 2019 at 08:19:18AM +1000, Nyall Dawson wrote:
> > On Sat, 31 Aug 2019 at 17:02, Sandro Santilli <[hidden email]> wrote:
>
> > > Do you know which commit dropped the backward compatibility, exactly ?
> > > Note that "something completely unused" (just re-reading your quoted
> > > text) was actually still used by QGIS itself...
> >
> > No, no idea sorry. It would have been 2-3 years ago now, and it was a
> > mass deletion commit, so git blame won't be much use. You may be able
> > to git blame qgsvectorlayer.cpp or qgsvectorlayerrenderer.cpp to find.
>
> Could this be the one?
>
>   commit 8e5fb436b702b9ab3d2112557f57e5a49cdea03a
>   Author: Martin Dobias <[hidden email]>
>   Date:   Wed Dec 14 09:45:39 2016 +0800
>
>       Remove QgsLabelingEngineInterface base class and implementation in QgsPalLabeling
>
>       It was ready to go for some time, just waiting for QgsMapRender that still used it.
>
>    src/core/qgsvectorlayerrenderer.cpp | 122
>   +++++++++++++++++++++++++++++++++----------------------------------------------------------------------
>    1 file changed, 39 insertions(+), 83 deletions(-)
>
> Unfortunately `git log --grep compat` doesn't give many hints,
> and the NEWS file doesn't have any section of broken backward
> compatibility for the 3.0 section either.

https://github.com/qgis/QGIS/commit/034147886448b49659ec658ddba08a7aa5794b7c

Just be aware that if you're thinking of restoring this code in master
-- it's extremely unlikely to be accepted. You'd need to instead port
it to a python plugin and take on the related maintenance burden
yourself.

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