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

[Chris Crook]

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.

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!

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.