Re: 256x256 px icons
On Aug 15 11:52, Warren Young wrote: On 8/12/2011 12:59 AM, Corinna Vinschen wrote: On Aug 11 15:06, Warren Young wrote: I haven't forgotten about my attempt, by the way. It's just become a bigger project than anticipated. I guess you're not waiting on me, which is fine. No, no, I'm curious. I present to you now, my magnum opus: http://etr-usa.com/cygwin/logo/boxed-hippo.ico Now *that*, my friends, is an angry hippo. Boy, is she pissed. I would be, too, if I had been confined to the box that long. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 256x256 px icons
On Aug 15 15:09, Warren Young wrote: On 8/15/2011 1:52 PM, Andy Koppe wrote: On 15 August 2011 18:52, Warren Young wrote: I present to you now, my magnum opus: http://etr-usa.com/cygwin/logo/boxed-hippo.ico Now *that*, my friends, is an angry hippo. :) That is rather impressive, and yep, that's not a happy hippo. Is this just for fun or are you proposing this at the setup.exe icon, A bit of both. in which case of course it would need further effort to make it work at small sizes. If this does win out over the current gray box icon, I'd say it should be used as-is for 256 px, and can probably be made legible at 48 px. At smaller sizes, I'd say the hippo will have to be evicted from the box. I'll leave as an open question whether the 32 px and below icons become hippo heads, or empty boxes, or C logos, or... The problem for me is that the Cygwin C is only a sidenote now, and that it lost its color. The C is the central brand, so it should have a matching exposition. Only few users will see the 256x256 version of the icon, most will see the 32x32 or 48x48, and in these cases the simple box with C is clearer afaics. This is posed 3D art, so now that I have the assets, I can re-pose and make new renderings fairly easily. About 90% of the effort of getting here was just bringing all the pieces together. I don't think this replaces the newly finalized C logo on the first setup.exe wizard page. I think the box motif works best for the .exe itself, the thing you click on to start unpacking things. Not so sure about that... http://cygwin.de/angry-hippo-setup.png I just hope the hippo is free art. I really like the 3D box, but I think it would be better to have a 3D Cygwin C hopping out of the box. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 256x256 px icons
On Aug 15 20:46, Andy Koppe wrote: On 14 August 2011 12:12, Corinna Vinschen wrote: Your attempts at 16x16, 24x24, and 32x32 definitely look better than mine. Also, somehow I seem to have broken the terminal frame in 32x32. I didn't notice that before, but in direct comparison with your 32x32 it's quite obvious. As for 48x48 and 64x64, it seems the thicker original stroke results in a washed-out looking stroke in the inner part of the C, just below the wedge. Can you get rid of that washed-out look? I see what you mean. I think it's because the scaled-down stroke is less than a pixel wide in theory, but due to its position it ends up being divided between two pixel lines, so you get a two-pixel darkish grey instead of a one-pixel light grey. Fixing this would require redrawing the C at the high resolution in such a way that it maps to whole pixels when scaling down. I'm afraid that's beyond my pay grade though. Warren, if you've got any more spare time to spend on this ... Meanwhile, attached is the same again but with the 48x48 from your current icon, and a 64x64 scaled down from your 256x256, because I didn't like the C in the current 64x64 being bigger in relation to the terminal frame than at the other sizes. The stroke probably is a bit too dark though ... I created a new 64x64 icon with smaller C. Other than that I made a longish comparison of the small 16x16 and 24x24 icons on various backgrounds, and in contrast to what I said above, I think I prefer the slightly darker frames. Please have a look at http://cygwin.de/cygwin-terminal-beveled.ico. I think that should really do it. Maybe a terminal or a setup box with just a green wedge? Hmm, interesting idea. Attempt attached, with wedge-in-terminal instead of the standalone logo at 16x16 and 24x24. I think I prefer the logo though. What? They are cute! I like them a lot. I'd like do the same with the setup icon. I still prefer the logo there because it provides a good connection between the 16x16 window icon and the 32x32 taskbar icon on Vista/7, as the logo is the same in both. Also, the logo is rather well established, whereas the green wedge on its own wouldn't necessarily be recognised as representing Cygwin. I agree. I tried that on the setup boxes and it just didn't look good. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: GCC dependencies (attn David Billinghurst)
On 14/08/2011 20:29, Yaakov (Cygwin/X) wrote: Looking at the code, the .exe handling is added in gcc/gcc.c. There are two macros: HOST_EXECUTABLE_SUFFIX (which adds .exe to the commands it calls (cc1/as/collect2/ld), and TARGET_EXECUTABLE_SUFFIX, which is used only for and in convert_filename() to change the output filename. But the latter is only used if: /* By default there is no special suffix for target executables. */ /* FIXME: when autoconf is fixed, remove the host check - dj */ #if defined(TARGET_EXECUTABLE_SUFFIX) defined(HOST_EXECUTABLE_SUFFIX) #define HAVE_TARGET_EXECUTABLE_SUFFIX #endif I may be new to the GCC code, but that just looks bogus. On Linux, HOST_EXECUTABLE_SUFFIX is obviously empty, but why should that control HAVE_TARGET_EXECUTABLE_SUFFIX? I've made a patch to change that, and am rebuilding cygwin-gcc with that now. If it works (and I don't see why it won't), I'll go ahead and respin releases with the patch. Dave, anything to add here? Perhaps ping DJ over on the GCC list to ask him if he remembers the context behind that comment; maybe whatever was the autoconf problem is indeed now fixed. cheers, DaveK
Re: 256x256 px icons
On 16 August 2011 10:08, Corinna Vinschen wrote: On Aug 15 20:46, Andy Koppe wrote: On 14 August 2011 12:12, Corinna Vinschen wrote: Your attempts at 16x16, 24x24, and 32x32 definitely look better than mine. Also, somehow I seem to have broken the terminal frame in 32x32. I didn't notice that before, but in direct comparison with your 32x32 it's quite obvious. As for 48x48 and 64x64, it seems the thicker original stroke results in a washed-out looking stroke in the inner part of the C, just below the wedge. Can you get rid of that washed-out look? I see what you mean. I think it's because the scaled-down stroke is less than a pixel wide in theory, but due to its position it ends up being divided between two pixel lines, so you get a two-pixel darkish grey instead of a one-pixel light grey. Fixing this would require redrawing the C at the high resolution in such a way that it maps to whole pixels when scaling down. I'm afraid that's beyond my pay grade though. Warren, if you've got any more spare time to spend on this ... Meanwhile, attached is the same again but with the 48x48 from your current icon, and a 64x64 scaled down from your 256x256, because I didn't like the C in the current 64x64 being bigger in relation to the terminal frame than at the other sizes. The stroke probably is a bit too dark though ... I created a new 64x64 icon with smaller C. Other than that I made a longish comparison of the small 16x16 and 24x24 icons on various backgrounds, and in contrast to what I said above, I think I prefer the slightly darker frames. Fair enough. Compared to mine though it looks a bit rougher around the edges when used in a mintty window frame with dark background. In particular, some of the corner pixels stick out and the wedge has more pronounced stepping. (See attached pic.) I wonder whether this is due to resizing algorithm. Can you be bothered to try different scaling algorithms, or send me the orignal so I can have a go with Paint.net (which says it uses supersampling)? Andy compare.png.gz Description: GNU Zip compressed data
Re: 256x256 px icons
On Aug 16 15:16, Andy Koppe wrote: On 16 August 2011 10:08, Corinna Vinschen wrote: I created a new 64x64 icon with smaller C. Other than that I made a longish comparison of the small 16x16 and 24x24 icons on various backgrounds, and in contrast to what I said above, I think I prefer the slightly darker frames. Fair enough. Compared to mine though it looks a bit rougher around the edges when used in a mintty window frame with dark background. In particular, some of the corner pixels stick out and the wedge has more pronounced stepping. (See attached pic.) Sorry, but I really don't see that. Not in that size. Do I need specs? I wonder whether this is due to resizing algorithm. Can you be bothered to try different scaling algorithms, or send me the orignal so I can have a go with Paint.net (which says it uses supersampling)? I don't have an original other that what Warren sent: http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf http://etr-usa.com/cygwin/logo/beveled-for-small-composites.xcf Everything I did with the C I did from there. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 256x256 px icons
On 8/16/2011 1:50 AM, Corinna Vinschen wrote: On Aug 15 11:52, Warren Young wrote: Now *that*, my friends, is an angry hippo. Boy, is she pissed. I would be, too, if I had been confined to the box that long. The other way to look at it is that she is about to be unleashed upon the world. Fitting, for a setup program.
[RFU] {emacs,emacs-X11,emacs-el}-23.3-3
wget -x -nH --cut-dirs=2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-23.3-3-src.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-23.3-3.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-X11/emacs-X11-23.3-3.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-el/emacs-el-23.3-3.tar.bz2 Please leave the 23.3-2 packages as previous, and delete 23.3-1. Thanks. Ken
Re: 256x256 px icons
On 16 August 2011 15:31, Corinna Vinschen wrote: On Aug 16 15:16, Andy Koppe wrote: On 16 August 2011 10:08, Corinna Vinschen wrote: I created a new 64x64 icon with smaller C. Other than that I made a longish comparison of the small 16x16 and 24x24 icons on various backgrounds, and in contrast to what I said above, I think I prefer the slightly darker frames. Fair enough. Compared to mine though it looks a bit rougher around the edges when used in a mintty window frame with dark background. In particular, some of the corner pixels stick out and the wedge has more pronounced stepping. (See attached pic.) Sorry, but I really don't see that. Not in that size. Do I need specs? Aliasing is in the eye of the beholder. Or something. ;) I wonder whether this is due to resizing algorithm. Can you be bothered to try different scaling algorithms, or send me the orignal so I can have a go with Paint.net (which says it uses supersampling)? I don't have an original other that what Warren sent: http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf http://etr-usa.com/cygwin/logo/beveled-for-small-composites.xcf Everything I did with the C I did from there. Sorry, I meant the image before scaling, but including your changes. I'm not sure I could recreate them exactly (and it would take more time). Andy
Re: 256x256 px icons
On 8/16/2011 2:35 AM, Corinna Vinschen wrote: On 15 August 2011 18:52, Warren Young wrote: The problem for me is that the Cygwin C is only a sidenote now, and that it lost its color. On purpose. Few cardboard boxes have full-color logos on them. It would be trivial to bring back the color on the wedge. I had to go out of my way to desaturate it for the rendering. I may try that later. While I could lift the box flap enough to let the entire logo show, I think the partial obscuration helps sell the icon's illusion. The human mind is good at filling in missing bits, and gets a reward jolt when it figures out the mini puzzle. Next time you're at a newsstand, observe how many covers have something partially obscuring the title; same reason. In further service of selling the illusion, if I do decide to bring back the green on the wedge, I think I'll still keep it somewhat desaturated, as that's what happens when you print on kraft paper. You rarely see deep black print on a cardboard box. I don't think this replaces the newly finalized C logo on the first setup.exe wizard page. Not so sure about that... http://cygwin.de/angry-hippo-setup.png That works for me, too. I just thought you'd prefer the big C there instead, for branding. Hey, here's a thought: maybe the boxed hippo is a setup.exe Easter egg. Ctrl-RightShift-MiddleClick on a Thursday kind of thing. I just hope the hippo is free art. The licenses and ownership of all the pieces that went into the rendering allow me to provide renders to the project free and clear. The hippo model is free in the same way most fonts are free: I can't legally give you copies of the mesh and textures, but I can produce as many pixels as I'd like using it, and donate those pixels to an open source software project. See section 4 in the DAZ content EULA: http://www.daz3d.com/sections/aboutus/eula/EULA_Content.pdf If you want your own copy of the model, it's inexpensive: http://www.daz3d.com/i.x/shop/itemdetails/-/?item=4140 One could ask DAZ for a license to the mesh for the project, but I don't see that we really *need* that. Rendered pixels are what we're really after, no? Once we settle on the details, I can make nice high-res renders that would be free for future remixing. The program you need to pose the model is free-as-in-beer for now: http://www.daz3d.com/i/software/daz_studio It will go up to $50 soon, but DAZ says they'll be releasing a light version that may suit concurrently. (Reference: http://goo.gl/auQsp) (If you have any interest in playing with 3D, by the way, it's worth spending an evening playing with DAZ Studio. Play with Google SketchUp, too. Continue to ignore Blender. :) ) If someone wants it, I can give out the DAZ Studio pose preset for the hippo. With it, a single click will pose the model the way I did for my render. I made the cardboard box model, and will give it to anyone who asks. The cardboard texture is a heavily-hacked version of this photo: http://flic.kr/p/5EYA5Y My version evens out the lighting and removes the distortion in order to make it a seamless texture. I recolored it as part of that process. The original is licensed CC-by 2.0. My read of the license is that I can probably give out my version, since it's different enough to qualify as remixed art. Attribution shouldn't be a problem, since the photographer disclaims the need for it on the photo's Flickr page. (You're being attributed here and now, Jacob Gube!) The recycle icon on the box's front is like the hippo model: I can't give you the vectors, but anyone with a dingbat font installed probably has a direct substitute on hand. I suppose it would be legal to give out the raster texture I made from the vectors. So, bottom line, yes, some non-free software and non-free assets went into this composition. But if you're still feeling your RMS senses tingling, ask yourself this: if I had managed to photograph this scene instead, would you be insisting that I provide[*] copies of my camera, the box, and the hippo before you could use the photo? [*] For a reasonable shipping charge as provided under section 1 of the GPL v3, of course, insofar as shipping a hippo is reasonable. I really like the 3D box, but I think it would be better to have a 3D Cygwin C hopping out of the box. I can give that a try, too. But dang it, I *like* the angry hippo. :) Maybe the box art stays the same, and both a hippo *and* a beveled Cygwin logo are flying out of it...h...
Updated package: libusb-win32 1.2.5.0-1
Hello, There is a new version 1.2.5.0-1 of libusb-win32, please upload http://brl.thefreecat.org/libusb-win32/libusb-win32-1.2.5.0-1.tar.bz2 http://brl.thefreecat.org/libusb-win32/libusb-win32-src-1.2.5.0-1.tar.bz2 and please keep version 0.1.12.2-1 as old. Samuel
Re: [ITP] pbzip2 (and what was the upshot on pbzip2/libbz2 incompatibility?)
On 8/9/11 11:51 AM, Peter Li wrote: In light of this, perhaps I should benchmark the cygwin compiled version to make sure it is reasonable to use this rather than insisting on the windows binary. Will report back. P Not too surprising, but the Cygwin version does fine. Rough benchmarks on my 2 core hyperthreaded laptop decompressing a 900K block size 1.5 GB data file: bzip2: ~ 180 s pbzip2 Cygwin: 93 s pbzip2 win32 native: 86 s Will announce. P
Updated package: libusb-1.0 1.0.8+git20110720-1
Hello, There is a new version 1.0.8+git20110720-1 of libusb-1.0, please upload http://brl.thefreecat.org/libusb1.0/libusb1.0-1.0.8+git20110720-1.tar.bz2 http://brl.thefreecat.org/libusb1.0/libusb1.0-1.0.8+git20110720-1-src.tar.bz2 http://brl.thefreecat.org/libusb1.0/libusb1.0-devel/libusb1.0-devel-1.0.8+git20110720-1.tar.bz2 and please keep version 1.0.7+gitbd62c472-1 as old. Samuel
