Was going to pick up this project again, but I have a question. Would it be more useful to (next) start filling in the larger icon sizes, or start adding icons that are in the "iconspecs" document but not yet in the program?
- Are all the icons listed in iconspecs.htm slated to be in Fz3? Will some be included before others?
- Do the unforseen problems wxAUI affect the 16/32/48 versions of icons? (i.e. does it delay the need for larger versions?) or... will a different library be used to switch icon sizes?
In both regards, it's nicer to see it in the program in context, while trying different icons (sizes and varieties). Also, I'll keep working towards a complete icon set to spec, but what is required to be considered for a selectable theme in Fz3?
Also, I included a version of the svg file I've been working with on my "development page", just to give an idea about what sort of form the eventual svg file(s) would take - for making other sizes, etc.
http://plurib.us/1shot/2007/filezilla-toolbar/
Toolbar button icons
Moderator: Project members
They'll be eventually used.Are all the icons listed in iconspecs.htm slated to be in Fz3? Will some be included before others?
Different icon sizes can be used even with the current toolbar implementation. So once larger icons are available, enabling them shouldn't be a problem.Do the unforseen problems wxAUI affect the 16/32/48 versions of icons? (i.e. does it delay the need for larger versions?) or... will a different library be used to switch icon sizes?
Your icon set already looks very good. At least from my side it's enough to be added to FZ3.Also, I'll keep working towards a complete icon set to spec, but what is required to be considered for a selectable theme in Fz3?
GreatAlso, I included a version of the svg file I've been working with on my "development page", just to give an idea about what sort of form the eventual svg file(s) would take - for making other sizes, etc.
http://plurib.us/1shot/2007/filezilla-toolbar/
I have finished at least something for all icon sizes in the "general toolbar". Same for the "transfer settings toolbar".
http://plurib.us/1shot/2007/filezilla-toolbar/
http://plurib.us/1shot/2007/filezilla-toolbar/
An update on my icon set:
I made 16px icons for the "browsing toolbar". My plan is to finish up the rest of the blank 16px versions (for a complete 16px icon set!), then start filling in the rest of the larger sizes (and probably redo file, folder, and folderclosed).
Toolbar icons on my development page are now officially GPL licensed.
I want to gage reaction of a few things on the new "browsing toolbar" icons:
* Is the chain in "synchronize" big enough to be recognizable? I'm thinking of a thicker version to compare, but if it's recognizable enough, I may let it be that size.
* Is what's going on in "compare" recognizable at all? I'm pretty happy with it, but I may be cramming too much into 16 pixels.
I made 16px icons for the "browsing toolbar". My plan is to finish up the rest of the blank 16px versions (for a complete 16px icon set!), then start filling in the rest of the larger sizes (and probably redo file, folder, and folderclosed).
Toolbar icons on my development page are now officially GPL licensed.
I want to gage reaction of a few things on the new "browsing toolbar" icons:
* Is the chain in "synchronize" big enough to be recognizable? I'm thinking of a thicker version to compare, but if it's recognizable enough, I may let it be that size.
* Is what's going on in "compare" recognizable at all? I'm pretty happy with it, but I may be cramming too much into 16 pixels.
Great idea! Here's a page that compares the quality of different OSS SVG renderers:botg wrote:Hmm, thinking about it, an SVG renderer in FZ3 would be nice. That way I could use all icon sizes imaginable.
http://www.linuxrising.org/svg_test/index.html
Then there's also http://www.amanith.org/ as an OpenVG implementation that can be used to render SVG e.g. in conjunction with http://developer.hybrid.fi/svgconv/.
I've been thinking of that [rendering the SVG directly], but I'd have a few concerns...
- I could see it working for sizes say, 48px or greater. The trouble with the smaller sizes, is there is a lot of cleanup I do on these icons to make them recognizable after they are exported. I don't think an exported/rendered SVG at 16px could ever be as crisp as one touched up (e.g. with a 1 pixel outline). The 32px version is on the fence, but it would probably look noticeably fuzzier than it could be.
- I assume a rendered SVG would overcome the transparency limitation in Windows? That would be nice but (and maybe it's just the way I've been working) again, only for the bigger sizes, where the anti-aliased-ness wouldn't affect the recognizability of features.
- This may sound strange, but I'm actually designing these SVGs around a 16 x 16 square grid (lining features up to the grid lines), so they export nicely to 16px, so I don't have to do as much cleanup on the exported versions (in 16, 32, or 48 as they're all multiples of 16). (Though not little enough that I'd say they look as good as the touched up PNG.) Exporting/rendering them as other in-between sizes (e.g. 20px) wouldn't have as good results in my particular SVGs.
- I could picture a system where Fz (or, some program) uses a PNG if it has one, and where there are none at the selected size (or, where there are none of that icon >= the selected size), it falls back to rendering SVG. I just wouldn't want sizes in between the PNG sizes to be selectable. (I can't quite picture that interface being intuitive right now, though). If it worked that way now, I'd entertain letting the SVG be rendered for the 48px, but I'd probably make the 16px and 32px myself.
- For my particular SVGs, gaussian blur would need to be supported. Some of the renderers on that site (from eyebex) didn't seem to. Inkscape just started to, Firefox 2.0 doesn't.
- I could see it working for sizes say, 48px or greater. The trouble with the smaller sizes, is there is a lot of cleanup I do on these icons to make them recognizable after they are exported. I don't think an exported/rendered SVG at 16px could ever be as crisp as one touched up (e.g. with a 1 pixel outline). The 32px version is on the fence, but it would probably look noticeably fuzzier than it could be.
- I assume a rendered SVG would overcome the transparency limitation in Windows? That would be nice but (and maybe it's just the way I've been working) again, only for the bigger sizes, where the anti-aliased-ness wouldn't affect the recognizability of features.
- This may sound strange, but I'm actually designing these SVGs around a 16 x 16 square grid (lining features up to the grid lines), so they export nicely to 16px, so I don't have to do as much cleanup on the exported versions (in 16, 32, or 48 as they're all multiples of 16). (Though not little enough that I'd say they look as good as the touched up PNG.) Exporting/rendering them as other in-between sizes (e.g. 20px) wouldn't have as good results in my particular SVGs.
- I could picture a system where Fz (or, some program) uses a PNG if it has one, and where there are none at the selected size (or, where there are none of that icon >= the selected size), it falls back to rendering SVG. I just wouldn't want sizes in between the PNG sizes to be selectable. (I can't quite picture that interface being intuitive right now, though). If it worked that way now, I'd entertain letting the SVG be rendered for the 48px, but I'd probably make the 16px and 32px myself.
- For my particular SVGs, gaussian blur would need to be supported. Some of the renderers on that site (from eyebex) didn't seem to. Inkscape just started to, Firefox 2.0 doesn't.
A new milestone: every icon is complete in 16px. ("complete", meaning "something is there." They may not be "final", whatever that means.) Comments continue to be welcome, especially on the sketches. 
See my development page.
I made a new zip of the theme file structure (current as of today). If there's anything I can do to make it easier for developers, let me know.
Also, I put out a few sample SVG icons of some of the more complicated designs. If someone wants to experiment with direct SVG rendering, this is probably the form the "original" SVG images would take.
See my development page.I made a new zip of the theme file structure (current as of today). If there's anything I can do to make it easier for developers, let me know.
Also, I put out a few sample SVG icons of some of the more complicated designs. If someone wants to experiment with direct SVG rendering, this is probably the form the "original" SVG images would take.
A few minor updates (just because it's been so long)... After making a way-too-dark "synchronize" icon, the globe in some of the other icons started bothering me. So I lightened them up a bit too (remotetreeview, disconnect, reconnect). And the Synchronize icon is now thicker, and I think a little more recognizable.
Also, I added a screenshot of the icon set running in Kubuntu (on my devopment page). Almost forgot Fz3 is cross platform!
Update: Browsing Toolbar icons are now complete with all sizes.
Also, I added a screenshot of the icon set running in Kubuntu (on my devopment page). Almost forgot Fz3 is cross platform!
Update: Browsing Toolbar icons are now complete with all sizes.
Ok, this icon set is finally complete, according to spec. I also updated the 1-file directory structure. Let me know if there are any changes needed or desired, or if there's anything else I can do. Thanks!
Botg, first, thanks for switching source control over to Subversion. Much easier to navigate & use, IMHO. 2nd, I just noticed now the Creative Commons note in the iconspecs document you added in May. Just wondering if you're under the impression that the CC-GNU GPL is not GPL compatible. I would contend the CC-GNU GPL legally *is* GPLv2. (However, probably all other CC licenses are indeed not GPL compatible.)
If you were under a different impression, I would be happy to express my license differently. (Or maybe I'm misinterpreting this whole thing...)
If you were under a different impression, I would be happy to express my license differently. (Or maybe I'm misinterpreting this whole thing...)