<div dir="ltr">Hi Olivier,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 20, 2013 at 8:52 AM, Olivier Dalang <span dir="ltr"><<a href="mailto:olivier.dalang@gmail.com" target="_blank">olivier.dalang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">By the way : is there some policy about backwards compatibility ?<br></blockquote><div><br></div><div>
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.<br>
<br></div><div>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.'<br>
<br>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Thanks !<br>
<br>
2013/2/20 Olivier Dalang <<a href="mailto:olivier.dalang@gmail.com">olivier.dalang@gmail.com</a>>:<br>
> Hi !<br>
><br>
> Those change appear because some properties have been added and some<br>
> removed to make the UI and the code more consistent (removing<br>
> duplicate border color settings for Shape item, for instance).<br>
> Upon opening an old project, the added properties will be set to<br>
> default, while the duplicate one will take the old unused property.<br>
><br>
> I'd say there's no easy way to avoid such side-effects (without coding<br>
> some dirty compatibility code). One way to handle such changes would<br>
> be to implement a kind of "old version file converter" to allow<br>
> backwards compatibility without making the code too complex.<br>
><br>
> But I'm not sure that if it's worth it. A general rule in software<br>
> usage is to keep the same version of the software throughout a<br>
> project, an to use new versions only when starting new projects<br></blockquote><div> <br></div><div>I don't think that's a general rule at all.<br><br>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.<br>
<br></div><div>Regards,<br><br></div><div>Larry<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> However, it is possible to discuss if which composer items should have<br>
> a background and/or frame by default. (in your case, this could change<br>
> whether composer items should have a background by default)<br>
><br>
> For now, I think all the composer items have a white background and no<br>
> frame by default, excepted the ComposerShape which has also a frame.<br>
><br>
><br>
> Olivier<br>
><br>
><br>
><br>
> 2013/2/20 Andreas Neumann <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>>:<br>
>> Hi,<br>
>><br>
>> With the recent modifications in print composer, while I agree that the UI<br>
>> has much improved, there are unfortunately also some side-effects. Here are<br>
>> two problems I have detected:<br>
>><br>
>> * legend boxes which had a white background now have a transparent<br>
>> background<br>
>> * Basic shapes (like rects, ellipses, triangles) that had a black border now<br>
>> have either no border or a white border<br>
>><br>
>> For organizations like us, with a lot of QGIS projects with a lot of<br>
>> different layouts, this is quite annoying if we have to manually change each<br>
>> of the projects.<br>
>><br>
>> But I am also aware that we are using master / unstable and that there are<br>
>> modifications. I can live with such changes but I assume that other users<br>
>> will have similar problems if backwards compatibility breaks.<br>
>><br>
>> Just to let you know - thanks for the improvements in the UI!<br>
>><br>
>> Andreas<br>
>><br>
>> --<br>
>> --<br>
>> Andreas Neumann<br>
>> Böschacherstrasse 10A<br>
>> 8624 Grüt (Gossau ZH)<br>
>> Switzerland<br>
>> _______________________________________________<br>
>> Qgis-developer mailing list<br>
>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><br></div></div></div>