bulia byak wrote:
Purely from your description, this may be a violation of the refactoring freeze. Is there any specific user-visible bug you're fixing or functionality you're adding? If not please revert this for now regardless of whether it was the right thing to do or not, because we agreed to not do any more refactoring until the release.
Here is some detailed explanation I couldn't write earlier. I'm not surprised by Jon's reaction since I nuked a large portion of the file in question. This wasn't refactoring though. I replaced a lot of rather weird and undocumented caching code (it was trying to add each icon as a stock item, which is not the right thing to do when using named icons) with 1 line adding builtin icons, because I discovered that doing so fixes the icons in the eraser toolbar: They are no longer blurred. There is a weird drawing issue instead where part of the icon is repeated, this may a bug in the drawing function of SPIcon. I also removed a function that was never actually executed to reduce the amount of code that needs to be further scrutinized. I tested this in GDB by setting a breakpoint. I found out why the named icons were not used on Windows: the index.theme file was missing (on Linux it is in /usr/share/icons/hicolor, but on Windows there is no system-wide copy of that file at all). The PNG icons are for use on Windows, because our devlibs do not contain the dependencies of GdkPixbuf's SVG loader, and it still doesn't work when I copy them manually (more information here: http://www.nabble.com/svg-pixbuf-loader-on-Windows-td18293105.html ). 16x16 and 24x24 sizes are sufficient, because our icons are designed to look crisp only at those resolutions, and rendering them from SVG does not give any noticeable visual improvement. So I think I'm slowly making progress towards really finalizing this feature.
One thing that might help you is if you got a virtual machine setup for and running Ubuntu 6.06 LTS (Dapper). That is an older OS that is still supported, so is a valid target platform.
I think dapper has its own version of Inkscape in its repos. Moreover it has GTK 2.8 - too low for current SVN. Testing on Hardy (8.04) might be a good idea though. My current machine is a bit underpowered for work in VM to be productive, but I hope to get a faster one before the 0.47 release
So it makes sense for me to take care of this, since I
have at least one system showing the problem (my OS X laptop) and I can observe the bugs before a fix and observe that after a fix the bugs go away without introducing more.
If you could help me iron out the issues on Mac OS X I would be very grateful, because I have no access to that platform. One more note, Jon: I'm pretty sure the code you added in main.cpp to look for icons in more places is redunant, though it won't cause wrong behavior. Firstly, we need to only add our system-wide icons dir there; user locations are already taken care of by GTK. Secondly, searching in g_get_user_data_dirs()/inkscape/icons isn't good, because paths like ~/.config/inkscape/icons won't exist (our .config dir is in uppercase). Searching in g_get_system_data_dirs()/inkscape/icons seems OK, but I'm not clear about the behavior of this when Inkscape is installed both in /usr/local and /usr, or in an entirely different prefix like /opt.
Regards, Krzysztof Kosiński