Joel Holdsworth joel@airwebreathe.org.uk writes:
@@ -188,6 +188,11 @@ filter: dummy .man.in.man: LC_ALL=C sed -e 's,@bindir@,$(bindir),g' -e 's,@dlldir@,$(dlldir),g' -e 's,@PACKAGE_STRING@,@PACKAGE_STRING@,g' $< >$@ || ($(RM) $@ && false)
+# Rules for icons
+ifdef SVG_SRCS
+# Depreciated icon build rule .svg.ico: $(RSVG) -w 16 -h 16 -f png $< $*-16.png $(RSVG) -w 32 -h 32 -f png $< $*-32.png @@ -195,6 +200,17 @@ filter: dummy $(ICOTOOL) -c -o $@ $*-16.png $*-32.png $*-48.png $(RM) $*-16.png $*-32.png $*-48.png
+else
+resources/%-32.png: resources/%.svg
- $(RSVG) -f png $< $@
+resources/%.ico : resources/%-*-4.png resources/%-*-8.png \
resources/%-16-32.png resources/%-32-32.png resources/%-48-32.png- $(ICOTOOL) -c -o $@ $^
+endif
That's GNU make specific, you can't do that.
Also please don't send such a huge patch series. The first step should be to get just one icon committed with the proper infrastructure. Then you can consider sending more of them, preferably one dll at a time.
Alexandre Julliard julliard@winehq.org wrote:
Joel Holdsworth joel@airwebreathe.org.uk writes:
@@ -188,6 +188,11 @@ filter: dummy .man.in.man: LC_ALL=C sed -e 's,@bindir@,$(bindir),g' -e 's,@dlldir@,$(dlldir),g' -e 's,@PACKAGE_STRING@,@PACKAGE_STRING@,g' $< >$@ || ($(RM) $@ && false) +# Rules for icons
+ifdef SVG_SRCS
+# Depreciated icon build rule .svg.ico: $(RSVG) -w 16 -h 16 -f png $< $*-16.png $(RSVG) -w 32 -h 32 -f png $< $*-32.png @@ -195,6 +200,17 @@ filter: dummy $(ICOTOOL) -c -o $@ $*-16.png $*-32.png $*-48.png $(RM) $*-16.png $*-32.png $*-48.png +else
+resources/%-32.png: resources/%.svg + $(RSVG) -f png $< $@
+resources/%.ico : resources/%-*-4.png resources/%-*-8.png \ + resources/%-16-32.png resources/%-32-32.png resources/%-48-32.png + $(ICOTOOL) -c -o $@ $^
+endif
That's GNU make specific, you can't do that.
Yes I wondered if that might be the case. Do you (or anyone) have any thoughts about how to approach this? The .svg.ico suffix rule that's present at the moment works if there's a 1:1 relationship; one svg results in one ico. My problem is that a 9:1 relationship is required. Do you have any suggestions about how to make a generic rule to do that? Does it require changes to makedep?
Also please don't send such a huge patch series. The first step should be to get just one icon committed with the proper infrastructure. Then you can consider sending more of them, preferably one dll at a time.Sure - I can understand that. The reason I sent so many was that I wanted to show you that I don't plan to leave a depreciated SVG build rule lying around. I also wanted you to see and comment on my approach of creating resources subdirectories in these dlls like user32 has, and then putting the icon images in these.
What do you think?
Joel Holdsworth
Joel Holdsworth joel@airwebreathe.org.uk writes:
Sure - I can understand that. The reason I sent so many was that I wanted to show you that I don't plan to leave a depreciated SVG build rule lying around. I also wanted you to see and comment on my approach of creating resources subdirectories in these dlls like user32 has, and then putting the icon images in these. What do you think?
I still think that having to commit 10 source files per icon is not acceptable, even with subdirectories.
I still think that having to commit 10 source files per icon is not acceptable, even with subdirectories.
I agree it is a lot of source files, but I don't see that that's a problem if they're stored neatly within a resources subdirectory. user32.dll has a lot of images, but that's not a problem for this reason. In fact by creating resources subdirectories surely I'm tidying? because it unclutters the mix of resources and source code in many dlls.
The issue is that the 9 images are never going to go away - a full XP icon has at least 9 independant hand crafted images to go into it. Vista and 7 icons have even more.
Now the question is what to do about it?
The two approaches I can see are to keep them independant and stored neatly, or to package them somehow.
Keeping them independant is ideal from the artist's point of view because the SVGs and PNGs can be viewed and editied in their native format.
I could package them together into an archive of some sort e.g. an icon.tar.gz file. That would make the build rules easier, but it would mean the individual images could not be individually versioned, and make them slightly harder to edit.
An alternative we discused was to use a .ico rather than a .tar.gz as an image repository. However this has several problems:
1. Ugly blurring of the line between source binary and compiled binary: The build rule becomes 1x.ico + 4x.svg -> .ico. Kinda circular.
2. .ico files are a real pain to work with from the artist's point of view. It's a very unusual image format.
3. It's so easy to screw up the icon's internal structure, or change the format of a sub-image without meaning to. Many image editor apps will not generate a byte for byte identical file in an open->edit->save process, and many image editors would subdly change the ico format, and git version history would not make that kind of change clear.
4. Even then you're still left with 4 images - 1x .ico and 3x .svg, so the problem is still pretty bad.
I favour the individual images approach, or I could do a package approach if you like, but I can't see how a .ico package could work. Do you see my problem?
Joel
Joel Holdsworth joel@airwebreathe.org.uk writes:
I still think that having to commit 10 source files per icon is not acceptable, even with subdirectories.
I agree it is a lot of source files, but I don't see that that's a problem if they're stored neatly within a resources subdirectory. user32.dll has a lot of images, but that's not a problem for this reason. In fact by creating resources subdirectories surely I'm tidying? because it unclutters the mix of resources and source code in many dlls.
The issue is that the 9 images are never going to go away - a full XP icon has at least 9 independant hand crafted images to go into it. Vista and 7 icons have even more.
As far as I understand it's possible to store everything in a single SVG file. I don't know if tools like inkscape can support this directly, but it's all XML so a simple perl wrapper should be able to do anything we need.
On 22 March 2010 at 15:37 Alexandre Julliard julliard@winehq.org wrote:
Joel Holdsworth joel@airwebreathe.org.uk writes:
I still think that having to commit 10 source files per icon is not acceptable, even with subdirectories.
I agree it is a lot of source files, but I don't see that that's a problem if they're stored neatly within a resources subdirectory. user32.dll has a lot of images, but that's not a problem for this reason. In fact by creating resources subdirectories surely I'm tidying? because it unclutters the mix of resources and source code in many dlls.
The issue is that the 9 images are never going to go away - a full XP icon has at least 9 independant hand crafted images to go into it. Vista and 7 icons have even more.
As far as I understand it's possible to store everything in a single SVG file. I don't know if tools like inkscape can support this directly, but it's all XML so a simple perl wrapper should be able to do anything we need.
It is possible with a multipage SVG (which Inkscape doesn't support yet, and can't be rendered RSVG) and embedded bitmaps for the hand tweaked images (which are at beta stage AFAIK). That's bad news, but these obstacles can be overcome by me spending a lot of my time (which these days is in really short supply) writing scripts in Perl, but that would require me to use Perl (which I don't know and would have to learn)*, and could take several more months.
It would also require a dependancy on some kind of command line image handling tool like ImageMagick or Python image stuff (which I'm sure you won't like) because RSVG only renders to 32-bit, but we need to output to 4-bit and 8-bit without screwing up these palette (which may be very hard).
The end result would be 1 file rather than 9, but in a format which is harder even than ico for artists to work with given the state of todays tools.
* I do use python though - is there any in the project?
Speaking personally: This project has already taken me over a year to get this far, and after all this painstaking work I'm really keen to get it out to the world, but I'm so short of time right now, and it feels like every time I try and submit, there are more of these never ending hoops to jump through. From my perspective I won't abandon this work that I've spent so much time on, but it's becoming this never ending nightmare of obstacles. I'm looking at the big picture and wondering; is turning a very minor mess of 9 files into 1 per icon really the best use of my time, when I could be productively contributing to areas of need within the FOSS world that will have a real effect on FOSS users.
I want to keep pursuing this and I respect your opinion very much as the veteron maintainer of this project. Your uncompromising comittment to quality has resulted in an excellent and long standing project, it's just that I'm finding the lack of flexibility quite hard to cope with. Is there no way we could compromise on this?
Joel
Hi Joel,
I'm piping up not because I can speak for Alexandre--I can't--but to express that you're not the only one interested in seeing this work merged.
It is possible with a multipage SVG (which Inkscape doesn't support yet, and can't be rendered RSVG) and embedded bitmaps for the hand tweaked images (which are at beta stage AFAIK). That's bad news, but these obstacles can be overcome by me spending a lot of my time (which these days is in really short supply) writing scripts in Perl, but that would require me to use Perl (which I don't know and would have to learn)*, and could take several more months.
You could also ask for help. I too am not a Perl hacker, but there are some on list.
It would also require a dependancy on some kind of command line image handling tool like ImageMagick or Python image stuff (which I'm sure you won't like) because RSVG only renders to 32-bit, but we need to output to 4-bit and 8-bit without screwing up these palette (which may be very hard).
ImageMagick, at least, is very commonly available. In my personal opinion, adding a dependency on it to build the icons doesn't seem onerous. We have stranger requirements elsewhere in the build.
The end result would be 1 file rather than 9, but in a format which is harder even than ico for artists to work with given the state of todays tools.
Perhaps, but assuming a script to generate .icos from the SVG exists, it seems that a mirror script to create the SVG from its source files mightn't be too hard. Given such a script, artists wouldn't need to reinvent that particular wheel, and at some point the need for it should disappear (assuming Inkscape implements support for multipage SVGs.)
- I do use python though - is there any in the project?
There isn't.
Speaking personally: This project has already taken me over a year to get this far, and after all this painstaking work I'm really keen to get it out to the world, but I'm so short of time right now, and it feels like every time I try and submit, there are more of these never ending hoops to jump through. From my perspective I won't abandon this work that I've spent so much time on, but it's becoming this never ending nightmare of obstacles. I'm looking at the big picture and wondering; is turning a very minor mess of 9 files into 1 per icon really the best use of my time, when I could be productively contributing to areas of need within the FOSS world that will have a real effect on FOSS users.
We feel your pain ;-) Think of it this way: assuming you take the time to do this right, the next contributor won't have as steep an obstacle to deal with. You're not just contributing artwork--which are much appreciated, believe me--you're improving the workflow for future artists.
Cheers, --Juan
Joel Holdsworth joel@airwebreathe.org.uk writes:
Speaking personally: This project has already taken me over a year to get this far, and after all this painstaking work I'm really keen to get it out to the world, but I'm so short of time right now, and it feels like every time I try and submit, there are more of these never ending hoops to jump through. From my perspective I won't abandon this work that I've spent so much time on, but it's becoming this never ending nightmare of obstacles. I'm looking at the big picture and wondering; is turning a very minor mess of 9 files into 1 per icon really the best use of my time, when I could be productively contributing to areas of need within the FOSS world that will have a real effect on FOSS users.
I want to keep pursuing this and I respect your opinion very much as the veteron maintainer of this project. Your uncompromising comittment to quality has resulted in an excellent and long standing project, it's just that I'm finding the lack of flexibility quite hard to cope with. Is there no way we could compromise on this?
I'm certainly open to suggestions on how to reduce the work needed for the first step, but it needs to be a step in the right direction. Adding 500 files and reorganizing many directories is not a good intermediate measure. I definitely want your work committed too, in fact I included it in the requirements for the 1.2 release; but I'm not willing to make a mess of the source tree just to get this in sooner, as I'm sure you understand.
I'm certainly open to suggestions on how to reduce the work needed for the first step, but it needs to be a step in the right direction. Adding 500 files and reorganizing many directories is not a good intermediate measure. I definitely want your work committed too, in fact I included it in the requirements for the 1.2 release; but I'm not willing to make a mess of the source tree just to get this in sooner, as I'm sure you understand.
Ok, thanks for letting me know. I'll investigate multipage SVG and see what I can come up with All the best Joel
Ok, I have good news and bad news.
The good news is that multipage is standard now in SVG 1.2, and it is possible to embed a raster image in the SVG if you encode it in base64. Embedded images are partially supported in inkscape via python extensions.
The bad news is that you can't set the canvas sizes of individual pages - only the orientation. Ideally we would set the bounding box of each page.
One solution would be to set the canvas size to some arbitrary size, then tag the individual pages with custom attributes from some kind of wine namespace extension, that would tell the renderer what boundary box to draw with, and what bit depth to sample to.
The alternative solution (which I favour) would be a one canvas workflow, which some Tango artists are using. This was the approach I took when I was making icons for Lumiera: http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob_plain;f=icons/svg/too...
In this solution you have a single page with multiple icon images present. You then place on top of these images "magic" invisible rectangles which have been tagged so that the renderer script knows to treat these as boundary boxes. For wine's purposes, you would then need embed to the canvas any raster images and tag these in a similar way which instructs the renderer to decode the base64 into a files. Multiple vector rendering would then combine together with multiple raster images unpacked, and these would be bundled into an ico.
The great advantage is that inkscape supports this stuff today, so it's not so bad for artists.
How does that sound?
Joel
Joel Holdsworth joel@airwebreathe.org.uk writes:
In this solution you have a single page with multiple icon images present. You then place on top of these images "magic" invisible rectangles which have been tagged so that the renderer script knows to treat these as boundary boxes. For wine's purposes, you would then need embed to the canvas any raster images and tag these in a similar way which instructs the renderer to decode the base64 into a files. Multiple vector rendering would then combine together with multiple raster images unpacked, and these would be bundled into an ico.
The great advantage is that inkscape supports this stuff today, so it's not so bad for artists.
How does that sound?
I would have to see what the Wine side scripts would look like, but it sounds promising.
-
Alexandre Julliard -
Joel Holdsworth -
Juan Lang