On 8 August 2016 at 10:36, Chris Crook <[email protected]> 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 [[email protected]] On Behalf Of > Nyall Dawson [[email protected]] > 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 > [email protected] > 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 [email protected]) 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. _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
