My first reaction is "please KISS", the XML project is already complicated, so I would stick to option 1. About usability, I really don't mind it. Having a zipped file is convenient when... I make a mess, editing the project file. There is already an enhancement proposal to optionally save the project to the database, it could be a good start for option 2, but the project is stored as raw content to accomodate future changes in any direction. Here are my two cents: don't try to automate everything, sometimes a touch of vi saves your day, and above all don't make it overly complicated for automation sake. c
On Mon, Jan 21, 2019 at 2:41 PM Hugo Mercier <hugo.merc...@oslandia.com> wrote: > 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 -- -------------------------------------------------------------------------- Carlo A. Bertelli Charta servizi e sistemi per il territorio e la storia ambientale srl Dipendenze del palazzo Doria, vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy) tel./fax +39(0)10 2475439 +39 0108566195 mobile:+39 393 1590711 e-mail: berte...@chartasrl.eu http://www.chartasrl.eu --------------------------------------------------------------------------
_______________________________________________ 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
