Re: [Bf-committers] Generating icons overwriting files in SVN.
sounds like this is fixed for now.. in the future, another possibility is to slightly extend the svg to png generation to bit compare the png pixels, and if they are the same, just touch the old instead of overwriting the new. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Generating icons overwriting files in SVN.
Some naive question: Why do you use incscape or imagemagic and not blender itself? In 2008 there was a nice plugin called Vectex, with the functionality of using native SVG as textures in Blender Render. With this plugin updated to latest blender version, it should be possible to rasterize the SVGs for buttons in blender itself. In worst case use a little scene with a plane and an ortho camera and render the buttons. http://code.google.com/p/vectex/ http://www.blendernation.com/2008/03/02/vectex-svg-vector-texture-plugin-for-blender/ http://blenderartists.org/forum/showthread.php?117889-Vectex-SVG-vector-texture-plugin-for-Blender Beside that would it be a nice feature to bring SVG support for textures back to blender. Or do I miss something here? Happy blending, Conz Am 26.08.2013 18:37, schrieb Brecht Van Lommel: I solved the OS X problem, just didn't commit the fix yet, is now committed in case this gets reenabled. Also, svn/git does not show the file as changed if the binary file is identical. But different inkscape versions or some date/time metadata may generate different files. Probably it's difficult to ensure you get identical files. If you wanted to solve this, you could do something like embed an md5 hash of the svg in the png file. Then if the hash is different overwrite the png, else just touch the file so the modified date is newer. Brecht. On Mon, Aug 26, 2013 at 2:15 PM, Campbell Barton ideasma...@gmail.com wrote: Thanks Bastian, Until recently we had to manually update all datatoc stuff (glsl, fonts fonts etc,) and it _did_ get annoying so appretiate improvements here even if there are some hiccups along the way. Rasterizer in Blender may not be such a big project if we can use some small SVG library that isnt pulling in many deps (or use some other more compact vector format that SVG can be converted into might be better). Just to note on 2 issues. I uninstalled inkscape to avoid blender useing it and now I get this message when building... No rule to make target `/usr/bin/inkscape', needed by `/src/blender/release/datafiles/blender_icons16.png'. Stop. Brecht also mentioned he had some error on OSX that X11 had not been started (inkscape must use X11 even when run in the command line). ImageMagick's SVG conversions from SVG look exact the same as inkscapes from my test so if this is added back at some point we could use that instead. On Mon, Aug 26, 2013 at 10: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 Bartonideasma...@gmail.comwrote: 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)
Re: [Bf-committers] Generating icons overwriting files in SVN.
Supporting SVG as a textures is a complete different topic. Here we're discussing building process itself,meaning to the time SVG-PNG conversion is needed there's no blender built yet. Adding extra dependency for this step i would consider a bad idea. And i still not sure we need to be smart here. IMO, when someone updates SVG he SHOULD update PNG as well. Also, it might worth defining owner of icons,who will update the files (as opposite to current everyone might just edit the icons and update them). IMO, that'd be nice practice anyway and no need to try writing any AI in cmake :) On Tue, Aug 27, 2013 at 3:02 PM, Constantin Rahn cr...@vrchannel.de wrote: Some naive question: Why do you use incscape or imagemagic and not blender itself? In 2008 there was a nice plugin called Vectex, with the functionality of using native SVG as textures in Blender Render. With this plugin updated to latest blender version, it should be possible to rasterize the SVGs for buttons in blender itself. In worst case use a little scene with a plane and an ortho camera and render the buttons. http://code.google.com/p/vectex/ http://www.blendernation.com/2008/03/02/vectex-svg-vector-texture-plugin-for-blender/ http://blenderartists.org/forum/showthread.php?117889-Vectex-SVG-vector-texture-plugin-for-Blender Beside that would it be a nice feature to bring SVG support for textures back to blender. Or do I miss something here? Happy blending, Conz Am 26.08.2013 18:37, schrieb Brecht Van Lommel: I solved the OS X problem, just didn't commit the fix yet, is now committed in case this gets reenabled. Also, svn/git does not show the file as changed if the binary file is identical. But different inkscape versions or some date/time metadata may generate different files. Probably it's difficult to ensure you get identical files. If you wanted to solve this, you could do something like embed an md5 hash of the svg in the png file. Then if the hash is different overwrite the png, else just touch the file so the modified date is newer. Brecht. On Mon, Aug 26, 2013 at 2:15 PM, Campbell Barton ideasma...@gmail.com wrote: Thanks Bastian, Until recently we had to manually update all datatoc stuff (glsl, fonts fonts etc,) and it _did_ get annoying so appretiate improvements here even if there are some hiccups along the way. Rasterizer in Blender may not be such a big project if we can use some small SVG library that isnt pulling in many deps (or use some other more compact vector format that SVG can be converted into might be better). Just to note on 2 issues. I uninstalled inkscape to avoid blender useing it and now I get this message when building... No rule to make target `/usr/bin/inkscape', needed by `/src/blender/release/datafiles/blender_icons16.png'. Stop. Brecht also mentioned he had some error on OSX that X11 had not been started (inkscape must use X11 even when run in the command line). ImageMagick's SVG conversions from SVG look exact the same as inkscapes from my test so if this is added back at some point we could use that instead. On Mon, Aug 26, 2013 at 10: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 Bartonideasma...@gmail.com wrote: Recently Bastian committed changes so changes to the SVG icons automatically generates new PNG's. In
Re: [Bf-committers] Generating icons overwriting files in SVN.
Ah sure, you are right, there is no blender at buildtime that could convert the PNGs. Am 27.08.2013 11:27, schrieb Sergey Sharybin: Supporting SVG as a textures is a complete different topic. Here we're discussing building process itself,meaning to the time SVG-PNG conversion is needed there's no blender built yet. Adding extra dependency for this step i would consider a bad idea. And i still not sure we need to be smart here. IMO, when someone updates SVG he SHOULD update PNG as well. Also, it might worth defining owner of icons,who will update the files (as opposite to current everyone might just edit the icons and update them). IMO, that'd be nice practice anyway and no need to try writing any AI in cmake :) On Tue, Aug 27, 2013 at 3:02 PM, Constantin Rahn cr...@vrchannel.de wrote: Some naive question: Why do you use incscape or imagemagic and not blender itself? In 2008 there was a nice plugin called Vectex, with the functionality of using native SVG as textures in Blender Render. With this plugin updated to latest blender version, it should be possible to rasterize the SVGs for buttons in blender itself. In worst case use a little scene with a plane and an ortho camera and render the buttons. http://code.google.com/p/vectex/ http://www.blendernation.com/2008/03/02/vectex-svg-vector-texture-plugin-for-blender/ http://blenderartists.org/forum/showthread.php?117889-Vectex-SVG-vector-texture-plugin-for-Blender Beside that would it be a nice feature to bring SVG support for textures back to blender. Or do I miss something here? Happy blending, Conz Am 26.08.2013 18:37, schrieb Brecht Van Lommel: I solved the OS X problem, just didn't commit the fix yet, is now committed in case this gets reenabled. Also, svn/git does not show the file as changed if the binary file is identical. But different inkscape versions or some date/time metadata may generate different files. Probably it's difficult to ensure you get identical files. If you wanted to solve this, you could do something like embed an md5 hash of the svg in the png file. Then if the hash is different overwrite the png, else just touch the file so the modified date is newer. Brecht. On Mon, Aug 26, 2013 at 2:15 PM, Campbell Barton ideasma...@gmail.com wrote: Thanks Bastian, Until recently we had to manually update all datatoc stuff (glsl, fonts fonts etc,) and it _did_ get annoying so appretiate improvements here even if there are some hiccups along the way. Rasterizer in Blender may not be such a big project if we can use some small SVG library that isnt pulling in many deps (or use some other more compact vector format that SVG can be converted into might be better). Just to note on 2 issues. I uninstalled inkscape to avoid blender useing it and now I get this message when building... No rule to make target `/usr/bin/inkscape', needed by `/src/blender/release/datafiles/blender_icons16.png'. Stop. Brecht also mentioned he had some error on OSX that X11 had not been started (inkscape must use X11 even when run in the command line). ImageMagick's SVG conversions from SVG look exact the same as inkscapes from my test so if this is added back at some point we could use that instead. On Mon, Aug 26, 2013 at 10: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 Bartonideasma...@gmail.com wrote: Recently Bastian committed changes so changes to the
Re: [Bf-committers] Generating icons overwriting files in SVN.
Added convenience target so you can run make icons from blenders source dir. On Tue, Aug 27, 2013 at 7:32 PM, Constantin Rahn cr...@vrchannel.de wrote: Ah sure, you are right, there is no blender at buildtime that could convert the PNGs. Am 27.08.2013 11:27, schrieb Sergey Sharybin: Supporting SVG as a textures is a complete different topic. Here we're discussing building process itself,meaning to the time SVG-PNG conversion is needed there's no blender built yet. Adding extra dependency for this step i would consider a bad idea. And i still not sure we need to be smart here. IMO, when someone updates SVG he SHOULD update PNG as well. Also, it might worth defining owner of icons,who will update the files (as opposite to current everyone might just edit the icons and update them). IMO, that'd be nice practice anyway and no need to try writing any AI in cmake :) On Tue, Aug 27, 2013 at 3:02 PM, Constantin Rahn cr...@vrchannel.de wrote: Some naive question: Why do you use incscape or imagemagic and not blender itself? In 2008 there was a nice plugin called Vectex, with the functionality of using native SVG as textures in Blender Render. With this plugin updated to latest blender version, it should be possible to rasterize the SVGs for buttons in blender itself. In worst case use a little scene with a plane and an ortho camera and render the buttons. http://code.google.com/p/vectex/ http://www.blendernation.com/2008/03/02/vectex-svg-vector-texture-plugin-for-blender/ http://blenderartists.org/forum/showthread.php?117889-Vectex-SVG-vector-texture-plugin-for-Blender Beside that would it be a nice feature to bring SVG support for textures back to blender. Or do I miss something here? Happy blending, Conz Am 26.08.2013 18:37, schrieb Brecht Van Lommel: I solved the OS X problem, just didn't commit the fix yet, is now committed in case this gets reenabled. Also, svn/git does not show the file as changed if the binary file is identical. But different inkscape versions or some date/time metadata may generate different files. Probably it's difficult to ensure you get identical files. If you wanted to solve this, you could do something like embed an md5 hash of the svg in the png file. Then if the hash is different overwrite the png, else just touch the file so the modified date is newer. Brecht. On Mon, Aug 26, 2013 at 2:15 PM, Campbell Barton ideasma...@gmail.com wrote: Thanks Bastian, Until recently we had to manually update all datatoc stuff (glsl, fonts fonts etc,) and it _did_ get annoying so appretiate improvements here even if there are some hiccups along the way. Rasterizer in Blender may not be such a big project if we can use some small SVG library that isnt pulling in many deps (or use some other more compact vector format that SVG can be converted into might be better). Just to note on 2 issues. I uninstalled inkscape to avoid blender useing it and now I get this message when building... No rule to make target `/usr/bin/inkscape', needed by `/src/blender/release/datafiles/blender_icons16.png'. Stop. Brecht also mentioned he had some error on OSX that X11 had not been started (inkscape must use X11 even when run in the command line). ImageMagick's SVG conversions from SVG look exact the same as inkscapes from my test so if this is added back at some point we could use that instead. On Mon, Aug 26, 2013 at 10: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
Re: [Bf-committers] Generating icons overwriting files in SVN.
Thanks Campbell, think this will do it for now! :) On 27/08/2013 12:06, Campbell Barton wrote: Added convenience target so you can run make icons from blenders source dir. On Tue, Aug 27, 2013 at 7:32 PM, Constantin Rahncr...@vrchannel.de wrote: Ah sure, you are right, there is no blender at buildtime that could convert the PNGs. Am 27.08.2013 11:27, schrieb Sergey Sharybin: Supporting SVG as a textures is a complete different topic. Here we're discussing building process itself,meaning to the time SVG-PNG conversion is needed there's no blender built yet. Adding extra dependency for this step i would consider a bad idea. And i still not sure we need to be smart here. IMO, when someone updates SVG he SHOULD update PNG as well. Also, it might worth defining owner of icons,who will update the files (as opposite to current everyone might just edit the icons and update them). IMO, that'd be nice practice anyway and no need to try writing any AI in cmake :) On Tue, Aug 27, 2013 at 3:02 PM, Constantin Rahncr...@vrchannel.de wrote: Some naive question: Why do you use incscape or imagemagic and not blender itself? In 2008 there was a nice plugin called Vectex, with the functionality of using native SVG as textures in Blender Render. With this plugin updated to latest blender version, it should be possible to rasterize the SVGs for buttons in blender itself. In worst case use a little scene with a plane and an ortho camera and render the buttons. http://code.google.com/p/vectex/ http://www.blendernation.com/2008/03/02/vectex-svg-vector-texture-plugin-for-blender/ http://blenderartists.org/forum/showthread.php?117889-Vectex-SVG-vector-texture-plugin-for-Blender Beside that would it be a nice feature to bring SVG support for textures back to blender. Or do I miss something here? Happy blending, Conz Am 26.08.2013 18:37, schrieb Brecht Van Lommel: I solved the OS X problem, just didn't commit the fix yet, is now committed in case this gets reenabled. Also, svn/git does not show the file as changed if the binary file is identical. But different inkscape versions or some date/time metadata may generate different files. Probably it's difficult to ensure you get identical files. If you wanted to solve this, you could do something like embed an md5 hash of the svg in the png file. Then if the hash is different overwrite the png, else just touch the file so the modified date is newer. Brecht. On Mon, Aug 26, 2013 at 2:15 PM, Campbell Bartonideasma...@gmail.com wrote: Thanks Bastian, Until recently we had to manually update all datatoc stuff (glsl, fonts fonts etc,) and it _did_ get annoying so appretiate improvements here even if there are some hiccups along the way. Rasterizer in Blender may not be such a big project if we can use some small SVG library that isnt pulling in many deps (or use some other more compact vector format that SVG can be converted into might be better). Just to note on 2 issues. I uninstalled inkscape to avoid blender useing it and now I get this message when building... No rule to make target `/usr/bin/inkscape', needed by `/src/blender/release/datafiles/blender_icons16.png'. Stop. Brecht also mentioned he had some error on OSX that X11 had not been started (inkscape must use X11 even when run in the command line). ImageMagick's SVG conversions from SVG look exact the same as inkscapes from my test so if this is added back at some point we could use that instead. On Mon, Aug 26, 2013 at 10: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
Re: [Bf-committers] Generating icons overwriting files in SVN.
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.comwrote: 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 -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Generating icons overwriting files in SVN.
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 Bartonideasma...@gmail.comwrote: 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
Re: [Bf-committers] Generating icons overwriting files in SVN.
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.frwrote: 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 Bartonideasma...@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
Re: [Bf-committers] Generating icons overwriting files in SVN.
Thanks Bastian, Until recently we had to manually update all datatoc stuff (glsl, fonts fonts etc,) and it _did_ get annoying so appretiate improvements here even if there are some hiccups along the way. Rasterizer in Blender may not be such a big project if we can use some small SVG library that isnt pulling in many deps (or use some other more compact vector format that SVG can be converted into might be better). Just to note on 2 issues. I uninstalled inkscape to avoid blender useing it and now I get this message when building... No rule to make target `/usr/bin/inkscape', needed by `/src/blender/release/datafiles/blender_icons16.png'. Stop. Brecht also mentioned he had some error on OSX that X11 had not been started (inkscape must use X11 even when run in the command line). ImageMagick's SVG conversions from SVG look exact the same as inkscapes from my test so if this is added back at some point we could use that instead. On Mon, Aug 26, 2013 at 10: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 Bartonideasma...@gmail.comwrote: 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Generating icons overwriting files in SVN.
I solved the OS X problem, just didn't commit the fix yet, is now committed in case this gets reenabled. Also, svn/git does not show the file as changed if the binary file is identical. But different inkscape versions or some date/time metadata may generate different files. Probably it's difficult to ensure you get identical files. If you wanted to solve this, you could do something like embed an md5 hash of the svg in the png file. Then if the hash is different overwrite the png, else just touch the file so the modified date is newer. Brecht. On Mon, Aug 26, 2013 at 2:15 PM, Campbell Barton ideasma...@gmail.com wrote: Thanks Bastian, Until recently we had to manually update all datatoc stuff (glsl, fonts fonts etc,) and it _did_ get annoying so appretiate improvements here even if there are some hiccups along the way. Rasterizer in Blender may not be such a big project if we can use some small SVG library that isnt pulling in many deps (or use some other more compact vector format that SVG can be converted into might be better). Just to note on 2 issues. I uninstalled inkscape to avoid blender useing it and now I get this message when building... No rule to make target `/usr/bin/inkscape', needed by `/src/blender/release/datafiles/blender_icons16.png'. Stop. Brecht also mentioned he had some error on OSX that X11 had not been started (inkscape must use X11 even when run in the command line). ImageMagick's SVG conversions from SVG look exact the same as inkscapes from my test so if this is added back at some point we could use that instead. On Mon, Aug 26, 2013 at 10: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 Bartonideasma...@gmail.comwrote: 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
Re: [Bf-committers] Generating icons overwriting files in SVN.
I thought this would be a non issue with cmake... As far as I know the cmake targets are only executed if the source dependencies change, so regeneration target shouldn't be called unless the svg files actually change. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Generating icons overwriting files in SVN.
Its based on timestamps, I copied my source dir, then restored it (which I *think* caused the PNG to be regenerated). On Tue, Aug 27, 2013 at 3:20 AM, Antony Riakiotakis kal...@gmail.com wrote: I thought this would be a non issue with cmake... As far as I know the cmake targets are only executed if the source dependencies change, so regeneration target shouldn't be called unless the svg files actually change. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
