[Qgis-developer] Print composer changes: several side-effects

Larry Shaffer larrys at dakotacarto.com
Wed Feb 20 11:14:58 PST 2013


Hi Olivier,

On Wed, Feb 20, 2013 at 8:52 AM, Olivier Dalang <olivier.dalang at gmail.com>wrote:

> By the way : is there some policy about backwards compatibility ?
>

I don't think there is a set policy. It's seems to be more case-by-case.
However, with 2.0 there are many changes which affect plugin developers and
some that affect users. IMO those that affect users should be kept to a
minimum, and ideally, transparent.

I think ensuring users can at least open the previous version's project
file should always be considered a top-of-the-list goal when doing a
redesign of code or the GUI. Version 2.0 is going to upset users if it
forces them to make updates to many preexisting project files, especially
if the only reasoning for the change is 'to make the UI and the code more
consistent.'

There has to be a good reason for making a change that forces users edit
many of their current project files upon opening them in the next version.

Thanks !
>
> 2013/2/20 Olivier Dalang <olivier.dalang at gmail.com>:
> > Hi !
> >
> > Those change appear because some properties have been added and some
> > removed to make the UI and the code more consistent (removing
> > duplicate border color settings for Shape item, for instance).
> > Upon opening an old project, the added properties will be set to
> > default, while the duplicate one will take the old unused property.
> >
> > I'd say there's no easy way to avoid such side-effects (without coding
> > some dirty compatibility code). One way to handle such changes would
> > be to implement a kind of "old version file converter" to allow
> > backwards compatibility without making the code too complex.
> >
> > But I'm not sure that if it's worth it. A general rule in software
> > usage is to keep the same version of the software throughout a
> > project, an to use new versions only when starting new projects
>

I don't think that's a general rule at all.

Users expect (rightly so) to be able to open their project files in the
next version of the program. Some of my software projects are over 10 years
old and have migrated through many versions of the software. This is also a
design goal of even companies like Adobe (who always ensures backward
compatibility of 1 version). As a user nothing aggravates me like needing
to find a user who has an Adobe Creative Suite version 4 to open a version
3 project, so it can be saved as version 4, so I can open it in version 5
(I skipped CS4 for financial reasons)... but, at least I can.

Regards,

Larry

> However, it is possible to discuss if which composer items should have
> > a background and/or frame by default. (in your case, this could change
> > whether composer items should have a background by default)
> >
> > For now, I think all the composer items have a white background and no
> > frame by default, excepted the ComposerShape which has also a frame.
> >
> >
> > Olivier
> >
> >
> >
> > 2013/2/20 Andreas Neumann <a.neumann at carto.net>:
> >> Hi,
> >>
> >> With the recent modifications in print composer, while I agree that the
> UI
> >> has much improved, there are unfortunately also some side-effects. Here
> are
> >> two problems I have detected:
> >>
> >> * legend boxes which had a white background now have a transparent
> >> background
> >> * Basic shapes (like rects, ellipses, triangles) that had a black
> border now
> >> have either no border or a white border
> >>
> >> For organizations like us, with a lot of QGIS projects with a lot of
> >> different layouts, this is quite annoying if we have to manually change
> each
> >> of the projects.
> >>
> >> But I am also aware that we are using master / unstable and that there
> are
> >> modifications. I can live with such changes but I assume that other
> users
> >> will have similar problems if backwards compatibility breaks.
> >>
> >> Just to let you know - thanks for the improvements in the UI!
> >>
> >> Andreas
> >>
> >> --
> >> --
> >> Andreas Neumann
> >> Böschacherstrasse 10A
> >> 8624 Grüt (Gossau ZH)
> >> Switzerland
> >> _______________________________________________
> >> Qgis-developer mailing list
> >> Qgis-developer at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130220/ce0322b7/attachment-0001.html>


More information about the Qgis-developer mailing list