First of all, thanks for the review, it pretty much outlines the issues I feel uneasy about as well. First, most of these issues are caused by SVG icon being scaled down (sometimes for a reason unknown to me and sometimes because of missing appropriate size variant). So I skip these, because we need to just finish other size and adjust them a little to keep them in sync with other icons. I seriously doubt we'll fix those in time for F10.
Now, for the rest.
The delete icon - yes, it looks different and I proposed we change it to something other. The discussion was postponed for after F10 release.
The close icon on tabs - yes, it is chopped off and I don't understand why. It has correct size and the icon itself isn't chopped off, but in *some* applications it looks this way :-/
The door icon - the doors are slightly opened, perhaps too little, and behind there is a black space. The two pixel width outline is because both door and the door-hole has it's own outline. I agree, it might need improvement.
System->Administration - yep, it probably needs rework to better fit with the style.
Shut Down - dunno if you remember, but at the time it was being created there were a lot of submission and for some reason we chose this on. But even after a half a year (IIRC) of seeing it everyday it looks a bit weird me.
Network - yep, an old style one. We need to use the new styled monitors for these...
Palm - agreed
Volume - I accepted it back when we were creating it, but it seems to me it actually uses different perspective from other icons...
Firefox, Thunderbird, OpenOffice = pain, while firefox being the best... Basically the toolbar icons are pretty much themable in firefox, thunderbird needs theme, openoffice needs theme. Not a decent citizens. Seeing that our mail client of choice is Evolution though, which works good with Echo, I'd guess Thuderbird hasn't the highest priority (and it does not even fit with the F9 default icon theme). For openoffice we would probably need to symlink/copy the echo icons into echo icon theme for openoffice... I don't know, how they handle it.
I'd very much like to hear Luya's opinion, but I don't feel like supporting Echo for F10 as default much longer...
Martin
2008/10/15 Martin Sourada martin.sourada@gmail.com:
First of all, thanks for the review, it pretty much outlines the issues I feel uneasy about as well. First, most of these issues are caused by SVG icon being scaled down (sometimes for a reason unknown to me and sometimes because of missing appropriate size variant).
Technical question, is this a result of a general limitation in the available svg rendering stack? I ask because was playing around with the python bindings for cairo and librsvg in another context and I was having trouble with scaling and rendering of some simple svg data. But I fully submit my problems could just be my own poor understanding of how to make it work.
-jef
On Wed, 2008-10-15 at 12:56 -0800, Jeff Spaleta wrote:
Technical question, is this a result of a general limitation in the available svg rendering stack? I ask because was playing around with the python bindings for cairo and librsvg in another context and I was having trouble with scaling and rendering of some simple svg data. But I fully submit my problems could just be my own poor understanding of how to make it work.
Partly yes. Not sure how exactly it is rendered with librsvg, but there are some differences to how inkscape renders it (especially with various filters like blur or mask applied), but some of it are just a problem of scaling down something that isn't optimised for the size you downscale it to (upscaling works better).
-jef
Martin
Martin Sourada wrote:
I'd very much like to hear Luya's opinion, but I don't feel like supporting Echo for F10 as default much longer...
It's amazing how much more calm, easy, and productive discussions like this are when the folks involved are level-headed and treat each other with respect.
Thanks, Martin!
~m
2008/10/15 Martin Sourada martin.sourada@gmail.com:
Partly yes. Not sure how exactly it is rendered with librsvg, but there are some differences to how inkscape renders it (especially with various filters like blur or mask applied),
My limited understanding is that we have several different svg interpreter codebases and the inkscape and nautilus don't share a common library in that regard.
I believe that nautilus and other gnome apps like eog are ultimately using librsvg via a the gdk pixbuf loader (svg_loader.so). But I don't think inkscape makes use of librsvg at all.
Does firefox also have its own svg rendering implementation?
What does KDE end up using to read svg files?
-jef
On Wed, 2008-10-15 at 14:44 -0800, Jeff Spaleta wrote:
Does firefox also have its own svg rendering implementation?
AFAIK yes and so does WebKit (probably all its ports).
What does KDE end up using to read svg files?
I don't know answer to that one...
-jef
Martin
2008/10/15 Martin Sourada martin.sourada@gmail.com:
AFAIK yes and so does WebKit (probably all its ports).
I wonder.... if we looked at these svg based icons at the same scale/resolution using different underlying renderers, would we end up seeing different problems? Can we even do that sort of rendering test? I wouldn't really know how to force WebKit's or inkscape's render to render to the same scale that is being done by the gtk icon codepath to make a side by side comparison possible.
-jef
Jeff Spaleta wrote:
What does KDE end up using to read svg files?
KDE's current support for svg is limited to svg-basic (or something like that), which means... not very good... yet.
Work is ongoing to leverage qt4/WebKit to improve this, but afaik, there's no eta for that turning into anything useful.
-- Rex
On Thu, Oct 16, 2008 at 4:22 AM, Rex Dieter rdieter@math.unl.edu wrote:
Work is ongoing to leverage qt4/WebKit to improve this, but afaik, there's no eta for that turning into anything useful.
I'll have to look at WebKit a little on my own I guess..since it seems to be the current buzzword.
My general and woefully uninformed feeling however is that, right now, we have a problem with the sophistication of our svg renders as exposed in desktop application frameworks and that's causing some non-trivial problems for graphical element development.
My understanding is that inkscape is using its own internal svg rendering codebase, which isn't exported as a library for other applications to make use of more directly. So we end up doing reasonably good artist svg work in this fabulous svg oriented application..but when we go to render the svg's later via rsvg, we don't get the results we expect. I'm guessing the KDE svg-basic thingie has similar problems.
Until the golden-age of WebKit supremacy arrives to save us, I'd love to be able to access inkscape's svg rendering into gtk directly as an alternative to librsvg, to do side by side comparisons, but I have no idea what that would take. If wishes were fishes, I'd be running my own fish oil dietary supplement factory.
-jef
Jeff Spaleta wrote:
My understanding is that inkscape is using its own internal svg rendering codebase, which isn't exported as a library for other applications to make use of more directly.
Inkscape uses Cairo AFAIK.
So we end up doing reasonably good artist svg work in this fabulous svg oriented application..but when we go to render the svg's later via rsvg, we don't get the results we expect. I'm guessing the KDE svg-basic thingie has similar problems.
Are we actually using svg for the icons? I was under the impression the artists are exporting them to PNG to various sizes (under the standard icon themes in /usr/share/gnome/icons follow) so that they match the pixel grid.
Even if the SVG renderer is perfect and flawless, it will never beat the artist hand-tweaking the artwork to render within the pixel grid per icon size.
~m
Máirín Duffy wrote:
Jeff Spaleta wrote:
My understanding is that inkscape is using its own internal svg rendering codebase, which isn't exported as a library for other applications to make use of more directly.
Inkscape uses Cairo AFAIK.
No, Inkscape uses Cario only in *some* places (outline view), the main rendering is made with its own engine. But while not perfect, these days Cario is quite good.
Are we actually using svg for the icons? I was under the impression the artists are exporting them to PNG to various sizes (under the standard icon themes in /usr/share/gnome/icons follow) so that they match the pixel grid.
Correct. Also PNGs are used for performance reason, they load faster and with less CPU use.
On Thu, Oct 16, 2008 at 11:13 PM, Nicu Buculei
No, Inkscape uses Cario only in *some* places (outline view), the main rendering is made with its own engine. But while not perfect, these days Cario is quite good.
I'm still trying to understand the actual codepath used when an svg file is loaded. Cairo has its own dialetic for drawing to a screen. My understanding is that for most gnome apps, they end up parsing the svg file with librsvg which can translate into cairo-speak. And that translation into native Cairo instructions...might have some issues.
-jef
desktop@lists.stg.fedoraproject.org
-
Jef Spaleta -
Martin Sourada -
Máirín Duffy -
Nicu Buculei -
Rex Dieter