Let's just punish those folks who updates svg but not re-generate png. Issue solved! :)
On Mon, Aug 26, 2013 at 6:06 PM, Bastien Montagne <montagn...@wanadoo.fr>wrote: > Hi folks, > > I made that change because I found out prvicons.png was no more in sync > with its svg "master" since a long time. I obviously agree that these > "false" changes to png are not nice (I did not expected them, thought > svn would stick to binary comparison to detect changes in binary files > :/ ). Additionally, it’s a bit a pita when sharing patches that add an > icon, reviewer also has to update png from svg... > > I’ll revert (or rather, comment) that change for now, but imho we really > need to find some way to avoid that kind of disparity, human are far too > much unreliable when it comes to such tasks! > > I like Sergey's solution (rasterize svg in Blender), but this is quite a > big project I fear. :/ > > On 26/08/2013 12:35, Sergey Sharybin wrote: > > Hi, > > > > Don't think generating PNG if Inkscape found and using PNG from SVN > > otherwise will work. We would still need to keep PNG up-to-date in svn, > so > > everyone is guaranteed to have up-to-date icons. > > > > Making inkscape/imagemagick a dependency is not a good thing to do as > well > > -- blender compilation is already really complicated. So i would rather > > avoid this. > > > > So from suggested alternatives i would prefer reverting that part of > > changes which generates PNG out of SVG at buildtime. We don't change > icons > > so much often anyway. > > > > As a long-term solution, think it's better to make SVG a native format > for > > icons. Meaning, blender will rasterize SVG itself. Would make any icons > > size look just as crisp as it could be :) > > > > > > On Mon, Aug 26, 2013 at 4:09 PM, Campbell Barton<ideasma...@gmail.com > >wrote: > > > >> Recently Bastian committed changes so changes to the SVG icons > >> automatically generates new PNG's. > >> > >> In general this is nice functionality to have, but it has some problems. > >> > >> The updated file thats generated overwrites the PNG in svn, > >> with changes to file modifiy times (moving files or dirs about), > >> its possible the PNG will get regenerated by building, even if the SVG > >> wasnt modified. > >> > >> So before committing you have to revert the change if it wasnt > intentional, > >> then manually touch the PNG so CMake isn't going to try generate the > >> image again. > >> > >> > >> Normally I check files before committing but sometimes I just commit > >> if I know I only edited a few files. > >> but generating overwriting files in svn means you can't be sure other > >> files aren't chagned too. > >> > >> > >> > >> Suggest 2 options... > >> > >> 1) Store _all_ generated files out of source, > >> (this was the case already before icon changes) > >> Note: since we currently don't have inkscape as a build dependency we > >> cant remove the PNG's from SVN, > >> but we could generate the file to the external dir, if inkscape > >> isn't found, just copy it from the one in svn. > >> This way we get the benefit of icon generation without accidentally > >> overwriting icons in svn. > >> > >> 2) revert icon generation as part of the build process for now. > >> > >> A third option could be to remove PNG's from SVN and make > >> inkscape/imagemagick a build dependency, > >> but think this makes building more trouble and dont really think its > >> such a good thing to do. > >> > >> > >> -- > >> - Campbell > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers