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

[Olivier Dalang]

Hi,

I absolutely agree about the fact that one should be able to open and
use file coming from a previous version.
What I wanted to say is that IMO minor glitches when doing so are
tolerable, and that if one cannot afford to spend some time correcting
those glitches (be it because it's a huge file or because there's an
urgent due), he'd better stick to the current version until he's ready
to take that time. And I also meant that as a rule for the user, not
for the programmer...

I think aiming at perfect backwards compatibility may prevent from
doing some necessary updates to keep a clean, understandable code and
thus a coherent and bug free user experience.

A good compromise would be to implement a "File version converter"
class which takes care of that without polluting the code, and
eventually telling the user what will be lost if passing from one
version to another. But that would be a huge work and hard to
maintain.

I also hate how Adobe manages that. I think they do it for the very
reason that they can't admit those glitches at all, but still change
their file format quite a lot. And it's particularly irritating since
you have to pay for each version, where in FOSS you can always
download and install any version you want.

I was asking because the same kind of question occurs often (see
Composer item's IDs for example), and since I'm a newcomer here I'll
adapt (of course :) ).

Regards,

Olivier




2013/2/20 Larry Shaffer <larrys at dakotacarto.com>:
> 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
>
>