Hi, On 21/01/2019 14:19, Régis Haubourg wrote: > Hi all, > > The initial plan - discussed some years ago on the lists - was to have a > container so that we can embed resources along the project file, and > open the door to a lot of nice features for sharing qgis projects. > The auxiliary data work was the opportunity to add this optional format > and checks the associated issues. > Then the idea was to switch to qgz by default and add features to save > resources (svg, fonts, datasets, etc...) into the project file. > > Unfortunately, the expected funding was discontinued and we are stuck > now with this default QGZ format, only storing the qgs and the qgd > files. (I think one should not hire a QGIS funder and expect fundings > keep coming afterwards :) ) > > The timing was bad also, because we only start since a few weeks to have > user feedback on this, like this issue https://issues.qgis.org/issues/20828 > > We also have feeback that QGZ makes things more complicated for qgs > maintenance tasks. > > I really don't know what to do: > > - switch back to classical qgs and let qgz get maturity. (But I'm afraid > we'll have very few real feedback then, just like during 3.0-3.2 period) > - give up qgz and bet on another option to offer a container (geopackage ) > - totally switch to qgz and offer a python lib for easing maintenance > tasks ?
I would vote for your 3rd proposition: replace xml hacking by something that looks like calls to an API. And adding an option for those who want to switch back to .qgs + separated aux files, keeping the default to .qgz. _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer