[Qgis-developer] QGIS 3 - breaking user projects?

[Nyall Dawson]

On 8 August 2016 at 10:36, Chris Crook <ccrook at linz.govt.nz> wrote:
> As an alternative to building and maintaining a bunch of translation code, how feasible would it be to build something like a python project migration tool?
>
> I'm not very familiar with the project XML structure but I'm wondering if it could be done using a python xml library which could update the appropriate bits of the project file without needing to handle the full structure (eg using libxml or something like that).   That would provide some support to users if their projects were broken by the updates without adding to the core code base.  (Similar idea to python 2to3 tool, but a lot simpler of course).  It needn't be perfect - if it handled 95% of cases then that would still be a great improvement.

That's a good alternative. The conversion wouldn't actually be that
complex - it's just a matter of time really.

>
> Note that while 2.6 may seem ancient history from a developer point of view, for users in secured corporate environments it can be difficult to get newer versions of software approved and installed.  I suspect that running older versions is more widespread than you might think!

Sounds like a perfect opportunity for one of these companies to step
up and sponsor this work...

Nyall


>
> Cheers
> Chris
>
> ________________________________________
> From: Qgis-developer [qgis-developer-bounces at lists.osgeo.org] On Behalf Of Nyall Dawson [nyall.dawson at gmail.com]
> Sent: 08 August 2016 11:22
> To: qgis-developer
> Subject: [Qgis-developer] QGIS 3 - breaking user projects?
>
> Hi all,
>
> I'm wondering - what's our stance on breaking users projects for QGIS
> 3 (in extreme circumstances, obviously)?
>
> There's 2 related changes I'd like to make:
>
>
>
> 1. Kill the old composer attribute table classes:
>
> I'd like to kill off the old composer attribute table classes. Here's
> the situation:
>
> - there's currently 2 type of attribute tables in composer, one is the
> old one which only allowed single frames, the other is the newer type
> which allows tables flowing across pages
> - since 2.6 all projects have created the newer composer tables - it's
> been impossible to create new tables using the old classes, but
> projects with existing old tables could still be used
>
> I'd now like to remove all the code regarding the original tables. It
> amounts to 1000s lines of mostly unused code. The side effect of this
> is that people loading pre 2.6 projects will be missing any attribute
> tables from composers.
>
> I think this is a fair option - 2.6 is ancient history and it's not a
> big deal to reinsert tables into a composer. Writing transition code
> to automatically upgrade the tables would be a couple of hours work
> which I cannot afford, and honestly seems like a waste of time to me.
>
>
>
> 2. Kill off some old expression variables
>
> I've also got a PR in place to clean up the expression classes
> (https://github.com/qgis/QGIS/pull/3364). These classes have got very
> messy and fragile since the introduction of expression
> contexts/variables (due to requirement to keep api compatiblity) and
> it's time to fix this. A side effect is that the use of the following
> "special columns" in expressions no longer works:
>
> $rownum (has been replaced by @row_number)
> $scale (has been replaced by @map_scale)
> $map (has been replaced by @map_id)
> $numpages (has been replaced by @layout_numpages)
> $page (has been replaced by @layout_page)
> $feature (has been replaced by @atlas_featurenumber)
> $atlasfeatureid (has been replaced by @atlas_featureid)
> $atlasfeature (has been replaced by @atlas_feature)
> $atlasgeometry (has been replaced by @atlas_geometry)
> $numfeatures (has been replaced by @atlas_totalfeatures)
>
> Expression variables have been around since 2.12, so there's been
> plenty of time for users to fix their expressions. Again, I've toyed
> with the idea of writing an automatic translator but
> 1. I don't have the time
> 2. It's always going to be fragile
> 3. Results in hundreds of lines of code which we'll have to drag around forever.
>
> I'd rather just make a note of these changes in the release notes and
> get users to upgrade their expressions to match. There's a few more
> I'd like to change/rename (eg $CURRENTDATE in composer labels - I
> never even knew this existed until looking at the code. I think it
> should be killed and replaced with a generic date('dd/mm/yy') type
> function).
>
>
>
> Thoughts?
>
> Nyall
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.