| Message ID | 24F20DD4-DD6D-4071-B45F-3CFF81AB419C@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 18/02/2015 22:09, Programmingkid wrote: > + # Take an image and make the image its own icon: > + sips -i ../pc-bios/qemu-nsis.ico > + # Extract the icon to its own resource file: > + DeRez -only icns ../pc-bios/qemu-nsis.ico > tmpicns.rsrc IIUC sips modifies ../pc-bios/qemu-nsis.ico (adding a resource fork?), so it's not possible to put it in Makefile.target. If "sips" is invoked twice by two different recursive invocations of Makefile.target, bad things can happen. I think we can simply distribute tmpicns.rsrc as pc-bios/qemu.rsrc instead. > + # append this resource to the file you want to icon-ize. > + Rez -append tmpicns.rsrc -o $(QEMU_PROG) > + > + # Use the resource to set the icon. > + SetFile -a C $(QEMU_PROG) These two commands can be added after $(QEMU_PROG_BUILD): $(all-obj-y) ../libqemuutil.a ../libqemustub.a $(call LINK,$^) instead of adding a new rule. There is no need for the comments. Paolo
On Feb 19, 2015, at 4:56 AM, Paolo Bonzini wrote: > > > On 18/02/2015 22:09, Programmingkid wrote: >> + # Take an image and make the image its own icon: >> + sips -i ../pc-bios/qemu-nsis.ico >> + # Extract the icon to its own resource file: >> + DeRez -only icns ../pc-bios/qemu-nsis.ico > tmpicns.rsrc > > IIUC sips modifies ../pc-bios/qemu-nsis.ico (adding a resource fork?), > so it's not possible to put it in Makefile.target. If "sips" is invoked > twice by two different recursive invocations of Makefile.target, bad > things can happen. > > I think we can simply distribute tmpicns.rsrc as pc-bios/qemu.rsrc instead. > >> + # append this resource to the file you want to icon-ize. >> + Rez -append tmpicns.rsrc -o $(QEMU_PROG) >> + >> + # Use the resource to set the icon. >> + SetFile -a C $(QEMU_PROG) > > These two commands can be added after > > $(QEMU_PROG_BUILD): $(all-obj-y) ../libqemuutil.a ../libqemustub.a > $(call LINK,$^) > > instead of adding a new rule. There is no need for the comments. > > Paolo Ok. Will implement your suggested changes. Thank you.
On 19 February 2015 at 18:56, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > On 18/02/2015 22:09, Programmingkid wrote: >> + # Take an image and make the image its own icon: >> + sips -i ../pc-bios/qemu-nsis.ico >> + # Extract the icon to its own resource file: >> + DeRez -only icns ../pc-bios/qemu-nsis.ico > tmpicns.rsrc > > IIUC sips modifies ../pc-bios/qemu-nsis.ico (adding a resource fork?), > so it's not possible to put it in Makefile.target. If "sips" is invoked > twice by two different recursive invocations of Makefile.target, bad > things can happen. > > I think we can simply distribute tmpicns.rsrc as pc-bios/qemu.rsrc instead. Why not just use the sips --out option to specify a different output file? That way we automatically put the current icon into the executable, and don't have to update a hand-created qemu.rsrc file in git if we change the icon in future (and I bet if we don't have the rules for doing this in the makefile then nobody will remember how to do it). As a bonus we don't have to keep that file full of ugly high-bit-set characters in C comments in git :-) -- PMM
On 20/02/2015 13:18, Peter Maydell wrote: > Why not just use the sips --out option to specify a different > output file? That way we automatically put the current icon > into the executable, and don't have to update a hand-created > qemu.rsrc file in git if we change the icon in future (and I > bet if we don't have the rules for doing this in the makefile > then nobody will remember how to do it). I suspect the Windows icon is not a great match for Mac OS X which likes to have big sizes (48x48 or 128x128). If you want to generate the .rsrc file automatically, the right source probably would be the .svg file, and doing the conversion in the Makefile probably isn't entirely feasible. It would need extra build dependency and rounding errors would make it harder to achieve reproducible builds. Paolo
On 20/02/2015 13:36, Paolo Bonzini wrote: > > > On 20/02/2015 13:18, Peter Maydell wrote: >> Why not just use the sips --out option to specify a different >> output file? That way we automatically put the current icon >> into the executable, and don't have to update a hand-created >> qemu.rsrc file in git if we change the icon in future (and I >> bet if we don't have the rules for doing this in the makefile >> then nobody will remember how to do it). > > I suspect the Windows icon is not a great match for Mac OS X which likes > to have big sizes (48x48 or 128x128). If you want to generate the .rsrc > file automatically, the right source probably would be the .svg file, > and doing the conversion in the Makefile probably isn't entirely > feasible. It would need extra build dependency and rounding errors > would make it harder to achieve reproducible builds. And depending on the complexity of the SVG not all methods produce the same result. Although it was years ago I recall having a hard time getting gradients to render correctly with ImageMagick. You'll want to compare the ImageMagick/GraphicsMagick and rsvg (apt:librsvg2-bin on Debian) outputs. Although the current ImageMagick seems to work fine on the logo here. But you'll have to find how to properly specify the size of the SVG (and not use -scale since it'll resize the bitmap, and make it 128x127). OTOH: rsvg-convert -w 128 -h 128 ./pc-bios/qemu_logo_no_text.svg > qemu-r.png seems to generate a proper png with transparency. It seems inkscape can do it as well, but it's probably a larger dependency: http://stackoverflow.com/questions/9853325/how-to-convert-a-svg-to-a-png-with-image-magick François.
On Feb 20, 2015, at 7:36 AM, Paolo Bonzini wrote: > > > On 20/02/2015 13:18, Peter Maydell wrote: >> Why not just use the sips --out option to specify a different >> output file? That way we automatically put the current icon >> into the executable, and don't have to update a hand-created >> qemu.rsrc file in git if we change the icon in future (and I >> bet if we don't have the rules for doing this in the makefile >> then nobody will remember how to do it). > > I suspect the Windows icon is not a great match for Mac OS X which likes > to have big sizes (48x48 or 128x128). Definitely true. > If you want to generate the .rsrc > file automatically, the right source probably would be the .svg file, > and doing the conversion in the Makefile probably isn't entirely > feasible. It would need extra build dependency and rounding errors > would make it harder to achieve reproducible builds. Plus the sips command doesn't work with svg files.
On 20/02/2015 17:54, Programmingkid wrote: >> I suspect the Windows icon is not a great match for Mac OS X which likes >> to have big sizes (48x48 or 128x128). > > Definitely true. > >> If you want to generate the .rsrc >> file automatically, the right source probably would be the .svg file, >> and doing the conversion in the Makefile probably isn't entirely >> feasible. It would need extra build dependency and rounding errors >> would make it harder to achieve reproducible builds. > > Plus the sips command doesn't work with svg files. Ok, so I'll apply v3 to my tree as soon as I get a Tested-by. Please take a look into providing a .rsrc file with larger-sized icons (I think you can add more than one to a single .rsrc file?) and, when you do that, document in pc-bios/README how the resources were built. Thanks, Paolo
On Feb 20, 2015, at 12:05 PM, Paolo Bonzini wrote: > > > On 20/02/2015 17:54, Programmingkid wrote: >>> I suspect the Windows icon is not a great match for Mac OS X which likes >>> to have big sizes (48x48 or 128x128). >> >> Definitely true. >> >>> If you want to generate the .rsrc >>> file automatically, the right source probably would be the .svg file, >>> and doing the conversion in the Makefile probably isn't entirely >>> feasible. It would need extra build dependency and rounding errors >>> would make it harder to achieve reproducible builds. >> >> Plus the sips command doesn't work with svg files. > > Ok, so I'll apply v3 to my tree as soon as I get a Tested-by. Please > take a look into providing a .rsrc file with larger-sized icons (I think > you can add more than one to a single .rsrc file?) and, when you do > that, document in pc-bios/README how the resources were built. When I was inspecting the icon using the genie feature of Mac OS X's dock, the icon looked very sharp at full size, so I didn't see a problem with it. What size do you have in mind?
On 20/02/2015 18:32, Programmingkid wrote: >> Ok, so I'll apply v3 to my tree as soon as I get a Tested-by. >> Please take a look into providing a .rsrc file with larger-sized >> icons (I think you can add more than one to a single .rsrc file?) >> and, when you do that, document in pc-bios/README how the >> resources were built. > > When I was inspecting the icon using the genie feature of Mac OS X's > dock, the icon looked very sharp at full size, so I didn't see a > problem with it. What size do you have in mind? I was thinking of 16x16, 32x32, 48x48 and 128x128. Paolo
On Feb 20, 2015, at 12:56 PM, Paolo Bonzini wrote: > > > On 20/02/2015 18:32, Programmingkid wrote: >>> Ok, so I'll apply v3 to my tree as soon as I get a Tested-by. >>> Please take a look into providing a .rsrc file with larger-sized >>> icons (I think you can add more than one to a single .rsrc file?) >>> and, when you do that, document in pc-bios/README how the >>> resources were built. >> >> When I was inspecting the icon using the genie feature of Mac OS X's >> dock, the icon looked very sharp at full size, so I didn't see a >> problem with it. What size do you have in mind? > > I was thinking of 16x16, 32x32, 48x48 and 128x128. What advantages do you think this would give us? Doesn't Mac OS X already resize the icon for you?
> > > When I was inspecting the icon using the genie feature of Mac OS X's > > > dock, the icon looked very sharp at full size, so I didn't see a > > > problem with it. What size do you have in mind? > > > > I was thinking of 16x16, 32x32, 48x48 and 128x128. > > What advantages do you think this would give us? Doesn't Mac OS X already resize the icon for you? 128x128 is used in the Finder in some cases IIRC. Downsizing from 128x128 to 16x16 isn't great, so whatever sizes are already in the .ico file should be kept (these are 16x16, 32x32 and 48x48) especially if you saw that the 48x48 icon is sharp in the dock. But remember that this is just a nit. Paolo
diff --git a/Makefile.target b/Makefile.target old mode 100644 new mode 100755 index e9ff1ee..e3679b4 --- a/Makefile.target +++ b/Makefile.target @@ -75,7 +75,7 @@ else stap: endif -all: $(PROGS) stap +all: $(PROGS) stap give_icon # Dummy command so that make thinks it has done something @true @@ -208,3 +208,22 @@ endif GENERATED_HEADERS += config-target.h Makefile: $(GENERATED_HEADERS) + +# Set the icon for QEMU on Macintosh +give_icon: + ifdef CONFIG_DARWIN + # Take an image and make the image its own icon: + sips -i ../pc-bios/qemu-nsis.ico + + # Extract the icon to its own resource file: + DeRez -only icns ../pc-bios/qemu-nsis.ico > tmpicns.rsrc + + # append this resource to the file you want to icon-ize. + Rez -append tmpicns.rsrc -o $(QEMU_PROG) + + # Use the resource to set the icon. + SetFile -a C $(QEMU_PROG) + + # clean up. + rm tmpicns.rsrc + endif
This patch adds the instruction to have the build commands give QEMU an icon. This code runs on Mac OS X. Signed-off-by: John Arbuckle <programmingkidx@gmail.com> --- Makefile.target | 21 ++++++++++++++++++++- 1 files changed, 20 insertions(+), 1 deletions(-) mode change 100644 => 100755 Makefile.target