All icons used in Inkscape should now be themable. You can find out the names by looking at the IDs in icons.svg, at icon names in in share/icons/hicolor/scalable/*, or at the file src/ui/icon-names.h.
All names are defined in a new file, ui/icon-names.h. This file should be used for all icon names used in Inkscape. I also removed stale files which attempted to do the same but weren't used universally (ui/stock.h, ui/stock-items.h, inkscape-stock.h).
Right now Inkscape uses the discrete SVG icons. I timed "hot" startup (using "time inkscape --verb FileQuit" twice and noting the second run) and it seems that it's actually faster (9.281s) than using icons.svg (9.799s), probably because the RSVG renderer which renders the SVG icons in Gnome is faster than ours.
Regards, Krzysztof Kosiński
On Feb 20, 2009, at 7:31 AM, Krzysztof Kosiński wrote:
Right now Inkscape uses the discrete SVG icons. I timed "hot" startup (using "time inkscape --verb FileQuit" twice and noting the second run) and it seems that it's actually faster (9.281s) than using icons.svg (9.799s), probably because the RSVG renderer which renders the SVG icons in Gnome is faster than ours.
Oh, but this will break a main intent we have.
Since the SVG spec does not allow for a multi-image resource in a standard way, we're implementing that ourselves in a work-around. RSVG not only does not support all the SVG aspects that Inkscape does, it definitely will not support a multi-image workaround.
That has been a main issue pushed by the icon authors out there, so will be a major setback.
Jon A. Cruz wrote:
Oh, but this will break a main intent we have.
The "intent" as I understand is to use a single file as the source for all scalable icons, for the designer's convenience. In that case the workflow can be preserved by creating a script that will extract the necessary discrete icons. I think this could be done using a clever XSLT transform.
Regards, Krzysztof Kosiński
On Feb 20, 2009, at 11:24 AM, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
Oh, but this will break a main intent we have.
The "intent" as I understand is to use a single file as the source for all scalable icons, for the designer's convenience. In that case the workflow can be preserved by creating a script that will extract the necessary discrete icons. I think this could be done using a clever XSLT transform.
No, no. That's a completely separate issue.
The primary reason for allowing Inkscape to render its own icons is that Inkscape usually does a better job of it. Only slightly less important is that Inkscape can have custom tweaks done to maximize the benefit of SVG.
We've been working on things for some time with the Tango people to be able to give them a nicer icon experience.
We're still at the point where most of the serious icon artists create in SVG but have to deploy in multiple PNG versions per icon due to the runtime limitations of current display engines.
Jon A. Cruz wrote:
The primary reason for allowing Inkscape to render its own icons is that Inkscape usually does a better job of it.
librsvg (used by Gnome) is sufficient to render all our icons - it causes no corruption or artifacts. It doesn' t support advanced features like masks or filters, but we're not using them in our current icons, and the Tango style doesn't use them either.
We're still at the point where most of the serious icon artists create in SVG but have to deploy in multiple PNG versions per icon due to the runtime limitations of current display engines.
I don't think it's only because of the limitations. Even with perfect SVG support I would still deploy in PNG, because it's faster to load. And with multiple sizes looking different, there's little reason not to deploy PNG. The solution is not for Inkscape to behave differently than the rest of the desktop, but rather to improve librsvg, or modularize Inkscape enough that its renderer could replace librsvg (I doubt if that's possible, because librsvg is SAX-based).
Regards, Krzysztof Kosiński
apologies in advance if it sounds like a silly idea, but what if the SVG->PNG conversion is done once a user sets a new icon theme? one would only need a check to see if the proper PNG files are already there. That way the PNGs wouldn't need to be bundled at all, and the check could be done at startup to ensure there would be no bad surprises. however, this approach wouldn't be suitable if direct SVG->PNG conversion is not desirable, as in the case of individual size tweaking...
:r
Krzysztof Kosiński wrote:
We're still at the point where most of the serious icon artists create in SVG but have to deploy in multiple PNG versions per icon due to the runtime limitations of current display engines.
I don't think it's only because of the limitations. Even with perfect SVG support I would still deploy in PNG, because it's faster to load. And with multiple sizes looking different, there's little reason not to deploy PNG. The solution is not for Inkscape to behave differently than the rest of the desktop, but rather to improve librsvg, or modularize Inkscape enough that its renderer could replace librsvg (I doubt if that's possible, because librsvg is SAX-based).
Regards, Krzysztof Kosiński
On Feb 24, 2009, at 8:00 AM, ricardo lafuente wrote:
pologies in advance if it sounds like a silly idea, but what if the SVG->PNG conversion is done once a user sets a new icon theme? one would only need a check to see if the proper PNG files are already there. That way the PNGs wouldn't need to be bundled at all, and the check could be done at startup to ensure there would be no bad surprises. however, this approach wouldn't be suitable if direct SVG->PNG conversion is not desirable, as in the case of individual size tweaking...
That might work, as long as it was also re-rendered each time the user switched display resolution or preferences for icon size.
On Feb 24, 2009, at 5:36 AM, Krzysztof Kosiński wrote:
We're still at the point where most of the serious icon artists create in SVG but have to deploy in multiple PNG versions per icon due to the runtime limitations of current display engines.
I don't think it's only because of the limitations. Even with perfect SVG support I would still deploy in PNG, because it's faster to load. And with multiple sizes looking different, there's little reason not to deploy PNG. The solution is not for Inkscape to behave differently than the rest of the desktop, but rather to improve librsvg, or modularize Inkscape enough that its renderer could replace librsvg (I doubt if that's possible, because librsvg is SAX-based).
You're missing the key point
Other people out there use different settings that get the icon sizes different. And nowadays with hi-res displays more and more common, allowing for that is more critical.
Scalable icons solve that problem. PNG do not.
Scalable icons solve that problem. PNG do not.
That's not quite true - scalable icons work fine for icons larger than 32x32. Almost all icons produce very poor results when rendered at small sizes, because smaller icons require manual tweaking - lines have to be moved on to pixel boundaries, the design may even have to be simplified.
This is why if you go down the SVG route you do need to have SVGs targetted to different size icons. Inkscape doesn't have this, and that's why the main toolbar which looks fuzzy not crisp in Ubuntu (and maybe others), because 16x16 icons are being stretched to 22x22.
Joel
Jon A. Cruz wrote:
Other people out there use different settings that get the icon sizes different. And nowadays with hi-res displays more and more common, allowing for that is more critical.
I know that very well; That's why I took the time to cut out the icons from icons.svg in the first place. Otherwise I would have just written a script that uses Inkscape to render the icons. However, the most common sizes are 24x24 and 16x16, and 32x32 for Windows desktop icons. Shipping those most used sizes means that only some icons have to be rendered from the vector. Moreover, I don't see how this relates to my modifications, since we're still using the scalable icons; the only thing that changed is that we're using a different renderer and "discrete" files instead of a monolithic one.
Did anybody try this on windows? I just did a clean build and I'm missing a *lot* of icons I guess you run Inkscape from the build tree without installing it. Regardless where you run Inkscape from, it looks for icons and other assets in the place it was installed. You need to install a daily build from after the change so that the icon files land in the appropriate places. Otherwise it won't work, just the way it wouldn't work if you built Inkscape and tried to run the built executable without having it installed in the regular location as well. I can put in some hacks to allow Inkscape to see the icons from the source tree, but this could make testing harder.
Regards, Krzysztof Kosiński
-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: dinsdag 24 februari 2009 23:09 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [NEW] Icon theming
I guess you run Inkscape from the build tree without installing it.
Of course.
Regardless where you run Inkscape from, it looks for icons and other assets in the place it was installed. You need to install a daily build from after the change so that the icon files land in the appropriate places.
Pretty sure Inkscape's daily builds cannot be installed. (it's just a zip of the build dir, afaik).
Otherwise it won't work, just the way it wouldn't work if you built Inkscape and tried to run the built executable without having it installed in the regular location as well. I can put in some hacks to allow Inkscape to see the icons from the source tree, but this could make testing harder.
Inkscape never needed installing; let's keep it that way.
Did anybody try this on windows? I just did a clean build and I'm missing a *lot* of icons (well over half the toolbar icons are not loaded) plus I get this in the commandline:
(inkscape.exe:3232): Gtk-WARNING **: Could not find the icon 'edit-select-all'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://icon-theme.freedesktop.org/releases
(inkscape.exe:3232): GLib-CRITICAL **: g_convert: assertion `str != NULL' failed
(inkscape.exe:3232): GLib-GIO-CRITICAL **: g_loadable_icon_load: assertion `G_IS_LOADABLE_ICON (icon)' failed
On Tue, Feb 24, 2009 at 5:05 PM, <J.B.C.Engelen@...1578...> wrote:
Did anybody try this on windows? I just did a clean build and I'm missing a *lot* of icons (well over half the toolbar icons are not loaded)
Same thing on Linux, 20770, after full make install. Come on guys, if we must do all this icon shuffling, can we at least do it a little less destructively? :)
On Win32: Still the 'edit-select-all' icon is not showing in the toolbar (but it is showing correctly in the edit menu)
Do I have to revert the icon change, again?
-----Original Message----- From: J.B.C.Engelen@...1578... [mailto:J.B.C.Engelen@...1578...] Sent: dinsdag 24 februari 2009 22:05 To: tweenk.pl@...400...; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [NEW] Icon theming
Did anybody try this on windows? I just did a clean build and I'm missing a *lot* of icons (well over half the toolbar icons are not loaded) plus I get this in the commandline:
(inkscape.exe:3232): Gtk-WARNING **: Could not find the icon 'edit-select-all'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://icon-theme.freedesktop.org/releases
(inkscape.exe:3232): GLib-CRITICAL **: g_convert: assertion `str != NULL' failed
(inkscape.exe:3232): GLib-GIO-CRITICAL **: g_loadable_icon_load: assertion `G_IS_LOADABLE_ICON (icon)' failed
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Feb 20, 2009 at 6:31 PM, Krzysztof Kosiński wrote:
All icons used in Inkscape should now be themable. You can find out the names by looking at the IDs in icons.svg, at icon names in in share/icons/hicolor/scalable/*, or at the file src/ui/icon-names.h.
All names are defined in a new file, ui/icon-names.h. This file should be used for all icon names used in Inkscape. I also removed stale files which attempted to do the same but weren't used universally (ui/stock.h, ui/stock-items.h, inkscape-stock.h).
And how does one use Tango icon theme again? :)
Alexandre
Alexandre Prokoudine wrote:
And how does one use Tango icon theme again? :)
You need to delete /usr/local/share/inkscape/icons/hicolor, and then replace icons.svg the usual way. Or you can place appropriately named icons in your global icon theme. I'll make the Tango icons the default for Linux once I find some time. I'm also pondering adding rasterized icons in 16x16 and 24x24, since only those sizes are used in Windows. The same mechanism could then be used on both platforms, and the custom SPIcon widget that I think is the source of the blurry icon problem could go away.
On the other hand, some people said that they want a single canvas workflow, but I think that the solution here is to use a build system to extract the discrete icons instead of hacking Inkscape to support this. All other apps and the Gnome and KDE desktops use discrete icons, so it would be needed anyway.
Regarding the edit-select all icon: It is probably a weird bug in select-toolbar.cpp because there is only one method to access the icons in icons.svg. All other icons display normally. I'm still in the process of finding out what's going on. The code for SPIcon is not exactly well organized.
Regards, Krzysztof Kosiński
On Sat, 2009-03-14 at 11:28 -0700, Krzysztof Kosiński wrote:
I'm also pondering adding rasterized icons in 16x16 and 24x24, since only those sizes are used in Windows.
No, it's not that only those are used. Rather those are the ones used by default.
Depending on things like the physical DPI of the display (my one work computer is physically 147 DPI) people like to get different settings. Of course on Win32 we still need to fix all the details of the GTK we build and ship.
Jon A. Cruz wrote:
No, it's not that only those are used. Rather those are the ones used by default.
In that case, we can ship the librsvg plugin for GdkPixbuf. Or we can write our own loader for SVG files based on Inkscape. The API looks rather simple. Here are the docs: http://library.gnome.org/devel/gdk-pixbuf/unstable/gdk-pixbuf-Module-Interfa...
Regards, Krzysztof Kosiński
On Sat, 2009-03-14 at 11:28 -0700, Krzysztof Kosiński wrote:
Regarding the edit-select all icon: It is probably a weird bug in select-toolbar.cpp because there is only one method to access the icons in icons.svg. All other icons display normally. I'm still in the process of finding out what's going on. The code for SPIcon is not exactly well organized.
Yes, I've been trying to explain that.
Our app now registers as a source of named icons. It needs to render and place the images in the source.
Then where we use icons we don't use the legacy SPIcon info directly, instead we just make the call/set things up to use named icons.
*If* no image exists for that in the current theme, then it falls back to one we placed. However if there is an icon in the current theme in the overall system, that will override the internal one we provided and thus follow the end-user's requests.
Finally, to follow the new "per-application" theme spec, all we need to do is locate the *dynamically* determined settings directory (changes at runtime due to the XDG directory spec), and add that directory to the list of sources searched for named icons.
Note that we want to move away from use of the "stock icon" and use the "named icon".
Look to gtk_icon_theme_append_search_path()
So... to summarize: The ancient SPIcon way was to do all the loading, rendering, caching, fetching and displaying was done directly. The newer way was changing a bit more to eventually *decouple* loading from display. We want to be a themed icon source and fill in our theme with internal images. Then whatever needs to use an icon just uses the themed icon loading to get it from the system, or ours as a fallback.
On Sat, 2009-03-14 at 12:41 -0700, Jon A. Cruz wrote:
So... to summarize: The ancient SPIcon way was to do all the loading, rendering, caching, fetching and displaying was done directly. The newer way was changing a bit more to eventually *decouple* loading from display. We want to be a themed icon source and fill in our theme with internal images. Then whatever needs to use an icon just uses the themed icon loading to get it from the system, or ours as a fallback.
For a bit more insight... take a look at GtkToolButton
http://library.gnome.org/devel/gtk/stable/GtkToolButton.html
The ancient way was for SodiPodi to create it's own SodiPodiButton, and add a SodiPodiIcon to it and run things itself.
The older GTK+ way was to use a stock_id and get a GtkToolButton with that stock id set and it would take care of the image fetching and such.
Then newer GTK+ way is now to use a named themed icon. http://library.gnome.org/devel/gtk/stable/GtkToolButton.html#gtk-tool-button...
Oh, one caveat is that stock items do more and are logically sized, whereas named themed icons do less (e.g. RTL vs. LTR) and are physically sized.
Jon A. Cruz wrote:
Our app now registers as a source of named icons. It needs to render and place the images in the source.
I'm not sure I understand this correctly. Do you mean the line in main.cpp adding INKSCAPE_PIXMAPDIR to the icon theme search path, or something else?
Finally, to follow the new "per-application" theme spec, all we need to do is locate the *dynamically* determined settings directory (changes at runtime due to the XDG directory spec), and add that directory to the list of sources searched for named icons.
We don't need to add any dynamically determined dirs anywhere. It's already done for us by GTK. It searches the current theme, regardless of whether it's in the user's ~/.icons directory, an XDG directory or in some system directory. This way if I choose a theme that has the "draw-rectangle" icon in the GNOME appearance properties dialog it is automatically used instead of our icon. This already works for e.g. the draw-eraser icon which I have in my theme.
Note that we want to move away from use of the "stock icon" and use the "named icon".
I removed all code that tried to use custom stock items some time ago because it wasn't used anywhere.
Regards, Krzysztof Kosiński
On Sat, 2009-03-14 at 13:04 -0700, Krzysztof Kosiński wrote:
Note that we want to move away from use of the "stock icon" and use
the
"named icon".
I removed all code that tried to use custom stock items some time ago because it wasn't used anywhere.
Hopefully it was truly dead code, and not code that just pushed things into the system so that other code could pull it out later.
Otherwise that was the "magic" that allowed things to start working. We really need that "magic".
On Sat, 2009-03-14 at 13:04 -0700, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
Our app now registers as a source of named icons. It needs to render
and
place the images in the source.
I'm not sure I understand this correctly. Do you mean the line in main.cpp adding INKSCAPE_PIXMAPDIR to the icon theme search path, or something else?
Something else.
INKSCAPE_PIXMAPDIR is something very old and broken, and needs major fixing. It also is a *major* issue when it comes to OS X, since packaging is different than on Linux.
Also... for the most part our code should migrate away from using that define.
We probably need to start a wiki page on this so that all platforms (Linux, Linux Autopackage, OS X and Windows) can get fixed and happy.
Jon A. Cruz wrote:
INKSCAPE_PIXMAPDIR is something very old and broken, and needs major fixing. It also is a *major* issue when it comes to OS X, since packaging is different than on Linux.
It should be defined at configure time, but someone decided to hardcode it relative to $(datadir) in path-prefix.h. Supposedly it is that way to support Autopackage. We need two things to fix it:
1. A way to set it (and other path defines) on configure time. Essentially, remove path-prefix.h and add some stuff to configure. 2. A set of functions that return those defined locations on Linux and figure out the correct absolute paths on Windows. Otherwise the CLI on Windows will remain totally broken because now we chdir to Inkscape's installation dir. The correct way is to build paths relative to the executable path fetched using GetModuleFileNameW.
Regards, Krzysztof Kosiński
Hi, everyone!!
Just thought I'd visit the maillist today. ^^
On 3/14/2009 4:22 PM, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
INKSCAPE_PIXMAPDIR is something very old and broken, and needs major fixing. It also is a *major* issue when it comes to OS X, since packaging is different than on Linux.
It should be defined at configure time, but someone decided to hardcode it relative to $(datadir) in path-prefix.h. Supposedly it is that way to support Autopackage. We need two things to fix it:
- A way to set it (and other path defines) on configure time. Essentially,
remove path-prefix.h and add some stuff to configure.
binreloc (upon which path-prefix.h is based) -fixes- problems. Now we have the choice of whether to have a static root or a settable root on Linux. We need to keep that.
- A set of functions that return those defined locations on Linux and
figure out the correct absolute paths on Windows. Otherwise the CLI on Windows will remain totally broken because now we chdir to Inkscape's installation dir.
Setting the current directory was to fix a different problem, with how executable searches are handled in Windows. The executable's dir and current dir are searched separately, unlike Linux. Like if you were in c:\a\b\c , and executed c:\f\g\h\something.exe, then 'c' and 'h' would both be searched, even if 'h' is not in PATH.
But, yes, I think the fix itself is broken and we need to handle it in a better way than cd-ing. SetCurrentDirectory() doesn't really affect paths very much. Maybe command-line stuff.
The correct way is to build paths relative to the executable path fetched using GetModuleFileNameW.
...which is how we mimic binreloc in Win32 (see prefix.cpp), and other things in Inkscape.
I suggest that we don't take away its current functionality (which does work fine for its purpose) but add to it. How about instead of a single root which is prepended to a resource name, we perform a search, like PATH does, or Java's classpath?
like instead of
resource = SOME_PATH_MACRO("specified/path");
resource = findSomeKindOfResource("specified/path");
This would allow the real files to be located in a variety/multitude of places, -including a cache-. A cache could be useful in the future. Mozilla does this. It would fix OSX's problem. And there could be a system and personal directory.
Also -- and we have been talking about this forever, and we really NEED to start thinking about implementing it -- stop using C or C++ strings for paths, and start using URIs. URI's not only have specific semantics, but their algorithms for resolve() and normalize() give predictable results for resource references. They would fix so many of these little problems with which we have been struggling.
actualURI = searchForResourceType(specifiedURI);
Whatever fixes we do, they need to be vanilla enough to work the same on at least our 3 main platforms identically. Linux-specific can be just as bad as Windows-specific.
(By the way, the only Win32 I use myself is this personal laptop. Everything at work is Unix).
bob
On Sat, 2009-03-14 at 17:48 -0500, Bob Jamison wrote:
resource = findSomeKindOfResource("specified/path");This would allow the real files to be located in a variety/multitude of places, -including a cache-. A cache could be useful in the future. Mozilla does this. It would fix OSX's problem. And there could be a system and personal directory.
Also -- and we have been talking about this forever, and we really NEED to start thinking about implementing it -- stop using C or C++ strings for paths, and start using URIs. URI's not only have specific semantics, but their algorithms for resolve() and normalize() give predictable results for resource references. They would fix so many of these little problems with which we have been struggling.
actualURI = searchForResourceType(specifiedURI);
Whatever fixes we do, they need to be vanilla enough to work the same on at least our 3 main platforms identically. Linux-specific can be just as bad as Windows-specific.
Yes. This is very good, and where we need to move to.
Aside from not using defines and/or direct path building, I agree that we need to switch completely away from strings.
However, we can't use URIs. Those will break for us. What we really need to do is use IRIs.
That probably the same general intent you were thinking, but the URI calls GTK+ has comply with the URI RFC, which causes them to fail on non-ASCII data.
On 3/14/2009 10:22 PM, Jon A. Cruz wrote:
On Sat, 2009-03-14 at 17:48 -0500, Bob Jamison wrote:
resource = findSomeKindOfResource("specified/path");This would allow the real files to be located in a variety/multitude of places, -including a cache-. A cache could be useful in the future. Mozilla does this. It would fix OSX's problem. And there could be a system and personal directory.
Also -- and we have been talking about this forever, and we really NEED to start thinking about implementing it -- stop using C or C++ strings for paths, and start using URIs. URI's not only have specific semantics, but their algorithms for resolve() and normalize() give predictable results for resource references. They would fix so many of these little problems with which we have been struggling.
actualURI = searchForResourceType(specifiedURI);
Whatever fixes we do, they need to be vanilla enough to work the same on at least our 3 main platforms identically. Linux-specific can be just as bad as Windows-specific.
Yes. This is very good, and where we need to move to.
Aside from not using defines and/or direct path building, I agree that we need to switch completely away from strings.
However, we can't use URIs. Those will break for us. What we really need to do is use IRIs.
That probably the same general intent you were thinking, but the URI calls GTK+ has comply with the URI RFC, which causes them to fail on non-ASCII data.
Well, that's what I -mean-, of course :-). Can't you read my mind by now? ^^
I have been meaning to work on the dom/uri code for a while, to handle IRIs. I don't think IRI is its own spec, but something like an addendum to URI. It's not so much the Unicode chars themselves, but how you handle escapes. But, yes, they would be so much nicer than what we have now.
The other uri.cpp, which is a wrapper of xml2's uri... I don't know if it can do IRI or not. Maybe that's in the libxml2 docs.
bob
On Sat, 2009-03-14 at 14:22 -0700, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
INKSCAPE_PIXMAPDIR is something very old and broken, and needs major fixing. It also is a *major* issue when it comes to OS X, since packaging is different than on Linux.
It should be defined at configure time, but someone decided to hardcode it relative to $(datadir) in path-prefix.h. Supposedly it is that way to support Autopackage. We need two things to fix it:
- A way to set it (and other path defines) on configure time. Essentially,
remove path-prefix.h and add some stuff to configure. 2. A set of functions that return those defined locations on Linux and figure out the correct absolute paths on Windows. Otherwise the CLI on Windows will remain totally broken because now we chdir to Inkscape's installation dir. The correct way is to build paths relative to the executable path fetched using GetModuleFileNameW.
It appears that you seem to be missing one of the main points of the XDG directory spec.
It allows for things to be changed at *runtime*, and per invocation.
Configure, build and install are all to early for best directory support.
Have you read through the XDG Base Directory Specification? We had many requests to support it well. Perhaps we should rough out some tables on a wiki page to show what affects which parts when.
One key one we're missing is loading configuration from $XDG_CONFIG_HOME and g_get_user_config_dir().
On Sat, 2009-03-14 at 13:04 -0700, Krzysztof Kosiński wrote:
Finally, to follow the new "per-application" theme spec, all we need
to
do is locate the *dynamically* determined settings directory
(changes at
runtime due to the XDG directory spec), and add that directory to
the
list of sources searched for named icons.
We don't need to add any dynamically determined dirs anywhere. It's already done for us by GTK. It searches the current theme, regardless of whether it's in the user's ~/.icons directory, an XDG directory or in some system directory. This way if I choose a theme that has the "draw-rectangle" icon in the GNOME appearance properties dialog it is automatically used instead of our icon. This already works for e.g. the draw-eraser icon which I have in my theme.
Yes, actually last time I checked we *do* need to add a directory for the new stuff to work.
That's the whole point of the "Themable Application-specific Icons" http://live.gnome.org/ThemableAppSpecificIcons
In fact, here's a copy-n-paste from their "specification"
In your application, where you initialize GTK+, you also want to do the following, so that your application will find these icons if the theme tree structure in use, doesn't provide them:
gtk_icon_theme_append_search_path (gtk_icon_theme_get_default (), APPNAME_DATA_DIR G_DIR_SEPARATOR_S "icons");
Now... the old way for applications was to hardcode their locations. Newer developments added support for the XDG directory specification. So we would want to use things like
g_get_system_data_dirs() and g_get_user_data_dir()
Then a user can change sets, themes being used, MRU, etc, just by launching with a different XDG environment variable set.
Jon A. Cruz wrote:
Now... the old way for applications was to hardcode their locations. Newer developments added support for the XDG directory specification. (...) Then a user can change sets, themes being used, MRU, etc, just by launching with a different XDG environment variable set.
You confuse assets with icon theming. It's very different from other things like markers or templates. APPNAME_DATA_DIR is not the user's data directory. It is the system-wide application data directory, e.g. /usr/share/inkscape. *We do not want to have any icons in Inkscape's user data dir.* If the theme author puts appropriately named icons in his theme to support Inkscape, and the user installs it, it just works. No need to put anything in Inkscape's directories.
The fallback order is: 1. The user's chosen theme. The theme author should provide icons for us here. This location is already in gtk_icon_theme_get_default(), and we mustn't touch it. 2. The system's fallback theme (hicolor). Same as above, it's already added to the search path by GTK. 3. Our icons from /usr/share/inkscape/icons. We use them if no one provided icons for us. This we must add using gtk_icon_theme_append_search_path(), to put it at the end.
Regards, Krzysztof Kosiński
On Sat, 14 Mar 2009 20:57:58 -0000, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
The fallback order is:
- The user's chosen theme. The theme author should provide icons for us
here. This location is already in gtk_icon_theme_get_default(), and we mustn't touch it. 2. The system's fallback theme (hicolor). Same as above, it's already added to the search path by GTK. 3. Our icons from /usr/share/inkscape/icons. We use them if no one provided icons for us. This we must add using gtk_icon_theme_append_search_path(), to put it at the end.
Regards, Krzysztof Kosiński
Currently (rev 20903) many of my icons are missing (or possibly scaled to 1x1, I'm not 100% sure). For example, on startup the "Draw Stars and Polygons" icon consists of two pixels, but if I open the actual svg file in /usr/share/inkscape/icons/hicolor/scalable/actions/ in Inkscape, the icon seems perfectly normal.
I uninstalled Gnome a couple of years ago after giving it a try (KDE went some years before that) and there is a reasonable chance that some old setting were left behind but I've no idea where. So, when you say that Inkscape is looking at the user's theme or the system's fallback theme, where do you actually mean?
At the moment Inkscape itself doesn't (AFAICS) have an option to just use the icons in /usr/share/inkscape/icons (which would be my personal default) so I can't really get a handle on what's happening to the icons even to say that the problem definately is being caused by old settings.
On Sat, 14 Mar 2009 22:04:46 -0000, Thomas Worthington <thomas@...2129...> wrote:
On Sat, 14 Mar 2009 20:57:58 -0000, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
The fallback order is:
- The user's chosen theme. The theme author should provide icons for us
here. This location is already in gtk_icon_theme_get_default(), and we mustn't touch it. 2. The system's fallback theme (hicolor). Same as above, it's already added to the search path by GTK. 3. Our icons from /usr/share/inkscape/icons. We use them if no one provided icons for us. This we must add using gtk_icon_theme_append_search_path(), to put it at the end.
Regards, Krzysztof Kosiński
Currently (rev 20903) many of my icons are missing (or possibly scaled to 1x1, I'm not 100% sure). For example, on startup the "Draw Stars and Polygons" icon consists of two pixels, but if I open the actual svg file in /usr/share/inkscape/icons/hicolor/scalable/actions/ in Inkscape, the icon seems perfectly normal.
I uninstalled Gnome a couple of years ago after giving it a try (KDE went some years before that) and there is a reasonable chance that some old setting were left behind but I've no idea where. So, when you say that Inkscape is looking at the user's theme or the system's fallback theme, where do you actually mean?
At the moment Inkscape itself doesn't (AFAICS) have an option to just use the icons in /usr/share/inkscape/icons (which would be my personal default) so I can't really get a handle on what's happening to the icons even to say that the problem definately is being caused by old settings.
Following on from this, I've now managed to determing that the icons being accessed are indeed the ones in /usr/local/share/inkscape/icons/hicolor and that if icons.svg is opened then all the icons display correctly, even the ones which do not correctly render on the toolbars.
In the process of testing this I discovered that the same icons which are defective on the toolbars also do not display correctly using Imagemagick's "display" command while the icons which do appear correctly in the toolbars also render correctly in Imagemagick.
I don't know if that moves things on at all, but there it is.
On Wed, 2009-03-18 at 20:00 +0000, Thomas Worthington wrote:
In the process of testing this I discovered that the same icons which are defective on the toolbars also do not display correctly using Imagemagick's "display" command while the icons which do appear correctly in the toolbars also render correctly in Imagemagick.
I don't know if that moves things on at all, but there it is.
Ah, yes. That does help.
It seems to confirm that the "eat your own dogfood" approach gave us 100% icon fidelity, whereas splitting things out to other rendering libs. holds us to problems with their implementation/compatibility
The one other thing that might help is if you check using Batik. That can help point out which ones are hitting bugs in Inkscape vs. which ones are hitting limitations in librsvg.
Thanks for investigating.
On Thu, 19 Mar 2009 04:09:41 -0000, Jon A. Cruz <jon@...18...> wrote:
On Wed, 2009-03-18 at 20:00 +0000, Thomas Worthington wrote:
In the process of testing this I discovered that the same icons which are defective on the toolbars also do not display correctly using Imagemagick's "display" command while the icons which do appear correctly in the toolbars also render correctly in Imagemagick.
I don't know if that moves things on at all, but there it is.
Ah, yes. That does help.
It seems to confirm that the "eat your own dogfood" approach gave us 100% icon fidelity, whereas splitting things out to other rendering libs. holds us to problems with their implementation/compatibility
The one other thing that might help is if you check using Batik. That can help point out which ones are hitting bugs in Inkscape vs. which ones are hitting limitations in librsvg.
Thanks for investigating.
Batik-squiggle does indeed display the icons correctly.
On Mar 19, 2009, at 7:42 AM, Thomas Worthington wrote:
Ah, yes. That does help.
It seems to confirm that the "eat your own dogfood" approach gave us 100% icon fidelity, whereas splitting things out to other rendering libs. holds us to problems with their implementation/compatibility
The one other thing that might help is if you check using Batik. That can help point out which ones are hitting bugs in Inkscape vs. which ones are hitting limitations in librsvg.
Thanks for investigating.
Batik-squiggle does indeed display the icons correctly.
Ah, thanks.
That means the problems are due to limitations in librsvg's implementation. We'll move forward with that info.
Oh, and in case anyone is wondering, I do know that the few people working on librsvg would be very welcoming to any coding help. So feel free to lend a hand.
On Fri, 20 Mar 2009 01:55:16 -0000, Jon A. Cruz <jon@...18...> wrote:
On Mar 19, 2009, at 7:42 AM, Thomas Worthington wrote:
Ah, yes. That does help.
It seems to confirm that the "eat your own dogfood" approach gave us 100% icon fidelity, whereas splitting things out to other rendering libs. holds us to problems with their implementation/compatibility
The one other thing that might help is if you check using Batik. That can help point out which ones are hitting bugs in Inkscape vs. which ones are hitting limitations in librsvg.
Thanks for investigating.
Batik-squiggle does indeed display the icons correctly.
Ah, thanks.
That means the problems are due to limitations in librsvg's implementation. We'll move forward with that info.
Oh, and in case anyone is wondering, I do know that the few people working on librsvg would be very welcoming to any coding help. So feel free to lend a hand.
Well, armed with the knowledge of where the problem was, I downloaded and installed the latest rsvg and the toolbars now work! I should have thought of that earlier, I guess, but that's always a problem with dependancies.
On Mar 20, 2009, at 9:31 AM, Thomas Worthington wrote:
Ah, thanks.
That means the problems are due to limitations in librsvg's implementation. We'll move forward with that info.
Oh, and in case anyone is wondering, I do know that the few people working on librsvg would be very welcoming to any coding help. So feel free to lend a hand.
Well, armed with the knowledge of where the problem was, I downloaded and installed the latest rsvg and the toolbars now work! I should have thought of that earlier, I guess, but that's always a problem with dependancies.
Can you let us know which version you had before, and which you are onto now?
I've been looking at adding some Schematron to check compatibility with various targets. This seems like a good use for that.
On Fri, 20 Mar 2009 16:56:13 -0000, Jon A. Cruz <jon@...18...> wrote:
On Mar 20, 2009, at 9:31 AM, Thomas Worthington wrote:
Ah, thanks.
That means the problems are due to limitations in librsvg's implementation. We'll move forward with that info.
Oh, and in case anyone is wondering, I do know that the few people working on librsvg would be very welcoming to any coding help. So feel free to lend a hand.
Well, armed with the knowledge of where the problem was, I downloaded and installed the latest rsvg and the toolbars now work! I should have thought of that earlier, I guess, but that's always a problem with dependancies.
Can you let us know which version you had before, and which you are onto now?
I've been looking at adding some Schematron to check compatibility with various targets. This seems like a good use for that.
I went from 2.16.1 to 2.22.3, which is the latest version in the Gentoo repository. The magnifying lens is fuzzy in this version but does at least appear in a recognisable form.
On Sat, 2009-03-14 at 13:57 -0700, Krzysztof Kosiński wrote:
The fallback order is:
- The user's chosen theme. The theme author should provide icons for
us here. This location is already in gtk_icon_theme_get_default(), and we mustn't touch it. 2. The system's fallback theme (hicolor). Same as above, it's already added to the search path by GTK. 3. Our icons from /usr/share/inkscape/icons. We use them if no one provided icons for us. This we must add using gtk_icon_theme_append_search_path(), to put it at the end.
#1 is not always in the path (hence the mention in the spec). Or rather we need to do a 1.5 for the custom thing.
Jon A. Cruz wrote:
- The user's chosen theme. The theme author should provide icons for
us here. This location is already in gtk_icon_theme_get_default(), and we mustn't touch it.
#1 is not always in the path (hence the mention in the spec). Or rather we need to do a 1.5 for the custom thing.
#1 is always in the path. "Default icon theme" means whatever the user has selected in the appearance dialog, not the Gnome theme or the hicolor theme. It's not the best choice of name but this is what it means in GTK. I also don't know what do you mean by "1.5". I already said that users do not put custom Inkscape icons in Inkscape's data dir, they install icon themes containing icons for Inkscape.
It appears that you seem to be missing one of the main points of the XDG directory spec.
I know what it's supposed to do, because this subject has been discussed to death. You can effectively run with a different set of user data and configuration by just tweaking an environment variable. However, XDG doesn't concern system-wide locations, only user locations. The configure stuff I was mentioning would be for system locations.
Bob Jamison wrote:
binreloc (upon which path-prefix.h is based) -fixes- problems. Now we have the choice of whether to have a static root or a settable root on Linux. We need to keep that.
With path-prefix we can only set the datadir at build time. Other paths are hardcoded relative to datadir. We cannot e.g. install icons in /opt/icons/inkscape (whatever might be the reason) and as I uderstand this is causing some issues with OSX packaging.
Also -- and we have been talking about this forever, and we really NEED to start thinking
about implementing it -- stop using C or C++ strings for paths, and start using URIs.
Simply using URIs instead of paths doesn't solve much, because we would still use hardcoded path (or URI) fragments in many places. A better solution would be to abstract away asset management (markers, palettes, gradients, dash patterns...) into a class, with functions like getTemplateList(), getMarkerList(), getPaletteList(), etc. (what those methods would return needs some thought.) That way the code that uses them need not be concerned with where those assets actually are and how they are accessed.
Regards, Krzysztof Kosiński
On Sun, 2009-03-15 at 16:26 -0700, Krzysztof Kosiński wrote:
Also -- and we have been talking about this forever, and we really NEED to start thinking
about implementing it -- stop using C or C++ strings for paths, and
start
using URIs.
Simply using URIs instead of paths doesn't solve much, because we would still use hardcoded path (or URI) fragments in many places. A better solution would be to abstract away asset management (markers, palettes, gradients, dash patterns...) into a class, with functions like getTemplateList(), getMarkerList(), getPaletteList(), etc. (what those methods would return needs some thought.) That way the code that uses them need not be concerned with where those assets actually are and how they are accessed.
Yes, and that was exactly what Bob was saying.
However, we have been doing more than talking about this. Code has been going in as people touch areas that address this.
Just help continue the code and add more. For example, there is a "Layer manager" now that acts as a facade to the layers so that code no longer grabs things from the object tree directly.
Also, *some* access of icons has been through the similar facade. However there are area where people have added their own code directly that does file loading.
We just need to clean those up as we go.
For example, there was coded added to the ColorDef class that loaded an icon from one of those fixed locations. I moved it up out of the ColorDef cpp.
(Ideally I'd move it to the standard icon call, but since that was changing I had waited)
But, yes, direct use of the pixmap dir constant should be refactored out.
On Sat, Mar 14, 2009 at 9:28 PM, Krzysztof Kosiński wrote:
And how does one use Tango icon theme again? :)
You need to delete /usr/local/share/inkscape/icons/hicolor, and then replace icons.svg the usual way.
Now that's an improvement over the previous implementation :-)
Or you can place appropriately named icons in your global icon theme.
You mean I have to slice tango_icons.svg to a lot of icons and put them somewhere inside /usr/share/inkscape/icons/?
Alexandre
On Sat, 2009-03-14 at 23:01 +0300, Alexandre Prokoudine wrote:
On Sat, Mar 14, 2009 at 9:28 PM, Krzysztof Kosiński wrote:
And how does one use Tango icon theme again? :)
You need to delete /usr/local/share/inkscape/icons/hicolor, and then replace icons.svg the usual way.
Now that's an improvement over the previous implementation :-)
Or you can place appropriately named icons in your global icon theme.
You mean I have to slice tango_icons.svg to a lot of icons and put them somewhere inside /usr/share/inkscape/icons/?
What we *need* to do is be sure the fallback order and the single-svg loading are properly back in place. Then it would still work with a custom theme of split icon files if needed, but would use the "just drop in one file" solution as a simple way for users to adjust.
It would even be trivial to add a preference to flip the search order for icons and files.
Now that's an improvement over the previous implementation :-) That's because I didn't have time to "slice" the Tango icons yet. Another way would be to extract them automatically but I'd have to define a mapping of old IDs to new names and fix Inkscape's command line SVG export, because right now it's rather broken. But fixing it right by defining a common set of operations that all output extensions should support (e.g. "hide everything except those IDs", "crop to drawing", etc.) and implementing them is a large task. This would be best done an the SVG level by preprocessing the SVG document given to the output/print extensions.
Alexandre Prokoudine wrote:
Or you can place appropriately named icons in your global icon theme.
You mean I have to slice tango_icons.svg to a lot of icons and put them somewhere inside /usr/share/inkscape/icons/?
Not there, but in your system-wide icon theme. Those are typically in /usr/share/icons. That's what all other Gnome applications do. Support for theming is a feature that has benefits only in the long run once people start incorporating icons for Inkscape into their themes.
Hopefully it was truly dead code, and not code that just pushed things
into the system so that other code could pull it out later. Otherwise that was the "magic" that allowed things to start working. We really need that "magic".
I think it was dead code, because SPIcon didn't actually look up stock items by the IDs that were defined in the headers. Additionally the stock icon code didn't even touch icons.svg. I think this was a part of the unfinished effort that left us with the unused EditWidget class.
Regards, Krzysztof Kosiński
participants (9)
-
unknown＠example.com -
Alexandre Prokoudine -
Bob Jamison -
bulia byak -
Joel Holdsworth -
Jon A. Cruz -
Krzysztof Kosiński -
ricardo lafuente -
Thomas Worthington