I have a patch that replaces SPIcon with GtkImage, by redefining sp_icon_new and typedefing SPIcon to GtkImage. The amount of changes is rather modest - about 10 files changed. It fixes all icon-related issues I could find but removes support for icons.svg.
http://tweenk.artfx.pl/kill-spicon.patch
Should I commit this?
Regards, Krzysztof Kosiński
Ed Halley wrote:
but removes support for icons.svg. Should I commit this?
Er, no, then.
You can still put custom icons in ~/.config/Inkscape/icons/hicolor, but you have to use the "discrete" format (like in the hicolor directory in the source tree).
Regards, Krzysztof Kosiński
On May 23, 2009, at 9:45 PM, Krzysztof Kosiński wrote:
Ed Halley wrote:
but removes support for icons.svg. Should I commit this?
Er, no, then.
You can still put custom icons in ~/.config/Inkscape/icons/hicolor, but you have to use the "discrete" format (like in the hicolor directory in the source tree).
Yes, I am aware of the purpose of the hicolor directory, but I think it's ridiculous to keep hundreds of icons as individual tiny files. Icons belong in sets, and I rather prefer the Inkscape icons.svg scheme to store whole sets at a time, viewable and adjustable all at once, identified by their group identifiers, not whole filenames.
-- [ e d @ h a l l e y . c c ]
On May 23, 2009, at 5:37 PM, Krzysztof Kosiński wrote:
I have a patch that replaces SPIcon with GtkImage, by redefining sp_icon_new and typedefing SPIcon to GtkImage. The amount of changes is rather modest - about 10 files changed. It fixes all icon-related issues I could find but removes support for icons.svg.
http://tweenk.artfx.pl/kill-spicon.patch
Should I commit this?
NO!!!!!
DO NOT COMMIT THAT!!!!!
YOU WILL BREAK THINGS YOU ARE NOT UNDERSTANDING. PLEASE WAIT AND LOOK TO OLDER PLATFORMS FIRST
DO NOT COMMITT
On Sat, 23 May 2009 18:45:13 -0700 (PDT), Krzysztof Kosiński <tweenk.pl@...400...> wrote:
but removes support for icons.svg. Should I commit this?
Er, no, then.
You can still put custom icons in ~/.config/Inkscape/icons/hicolor, but you have to use the "discrete" format (like in the hicolor directory in the source tree).
I don't mind removing SPIcon in favor of something more standard (at least in principle) but whatever you do *DO NOT* throw away support for icons.svg!
icons.svg has two important properties:
- it allows users to edit icon sets directly in inkscape without a separate bulk export step (so it is important for users)
- most rendering regressions are discovered when SVG icons render improperly in the UI (so it is important for testing)
Aside from my personal opinion that icons.svg should not be removed (which seems to be shared by a lot of people...), Jon Cruz has been more or less responsible for the the icons code up until now, so please follow his lead in this regard.
-mental
MenTaLguY wrote:
icons.svg has two important properties:
- it allows users to edit icon sets directly in inkscape without a
separate bulk export step (so it is important for users)
It is specific for Inkscape icons sets - it would be better if there was some kind of "export icon theme" option, that way authors of desktop icon sets (which must be in the discrete format) would also benefit.
As for Ed's opinion that icon sets should be in one SVG file: if used for the desktop, it would seriously degrade the performance, because an application that needs 5 icons would still need to load the SVG for every icon in the theme. With a single application this is less of an issue, but it can still cause a noticeable lag. We could already see this with the monolithic Tango icon theme, which contained a lot of unused variant icons and caused a big delay on startup (several seconds).
- most rendering regressions are discovered when SVG icons render
improperly in the UI (so it is important for testing)
Didn't think about this. But I suppose the rendering test suite from last year's GSoC has a greater potential to catch regressions.
That said, I won't commit this unless I come up with a way to support icons.svg too
Regards, Krzysztof Kosiński
On Sun, 2009-05-24 at 05:12 -0700, MenTaLguY wrote:
Aside from my personal opinion that icons.svg should not be removed
Just for the record, as I think that it doesn't get said enough, I'm -1 on keeping icons.svg. The critical failure that icons.svg brings is that there is no way for us to share icons with The GIMP. There is NO REASON we should have a different "Layer Up" icon than The GIMP and it is part of what makes the Free Software Graphics suite feel fragmented.
I realize that this mail won't solve the problem, but I think that it's important to realize that icons.svg does cause some problems for us.
--Ted
On May 25, 2009, at 6:57 AM, Ted Gould wrote:
On Sun, 2009-05-24 at 05:12 -0700, MenTaLguY wrote:
Aside from my personal opinion that icons.svg should not be removed
Just for the record, as I think that it doesn't get said enough, I'm -1 on keeping icons.svg. The critical failure that icons.svg brings is that there is no way for us to share icons with The GIMP. There is NO REASON we should have a different "Layer Up" icon than The GIMP and it is part of what makes the Free Software Graphics suite feel fragmented.
I realize that this mail won't solve the problem, but I think that it's important to realize that icons.svg does cause some problems for us.
Sharing icons with the GIMP would be a good thing... however...
1) They use a lot of their own custom work (code-wise, etc)
2) They are generally not wanting to bother sharing icons.
The latter is probably the bigger problem. As I've tried to push, shared icons need at least some coordination of names. That probably is the top thing blocking apps sharing icons. When the people were trying to coordinate the Art Libre naming set for creative icons, repeated attempts were made to get their feedback, but to no avail.
Now... since GIMP is not using stock mechanisms, we can't even get at their icons reliably if we wanted. So the user visible goal would be to display consistent icons with them... but to implement it we would have to have our own copies of the same image shapes but in different sizes, etc. Therefore in regards to this goal, the use of icons.svg is not blocking anything.
I do agree that it would be nice for apps to have unified icons; that was the whole goal of the Art Libre naming set. However, we've not been able to coordinate even names with the other main projects. (Blender, on the other hand, was interested but do their icons in a completely different manner where they have one large bitmap that they chop sprites from at runtime)
So again, icons.svg does not really cause that problem that is bothering you and me both.
On 05/25/2009 06:57 AM, Ted Gould wrote:
On Sun, 2009-05-24 at 05:12 -0700, MenTaLguY wrote:
Aside from my personal opinion that icons.svg should not be removed
Just for the record, as I think that it doesn't get said enough, I'm -1 on keeping icons.svg. The critical failure that icons.svg brings is that there is no way for us to share icons with The GIMP. There is NO REASON we should have a different "Layer Up" icon than The GIMP and it is part of what makes the Free Software Graphics suite feel fragmented.
I don't understand this notion that there is some Free Software Graphics Suite... rather than the icons even being considered as part of what makes it feel fragmented, what about starting with: UI design & Usability of apps are different, some TKs are different, and since "choice" is such a big deal with F/OSS stuff, many people don't even use the same tools. I think that the "Layer Up" icon is a great example of things that make sense to share... but, Tool-wise, the apps behave far too differently (imho) to even consider it.
Cheers, Josh
On Tue, 2009-05-26 at 20:33 +0400, Alexandre Prokoudine wrote:
On Mon, May 25, 2009 at 10:00 PM, Josh Andler wrote:
Tool-wise, the apps behave far too differently (imho) to even consider it.
Since you mention Inkscape and GIMP, what would be an example? :)
Actually, if you go back and re-read... I mentioned neither. ;)
Cheers, Josh
participants (8)
-
Alexandre Prokoudine -
Ed Halley -
Jon A. Cruz -
Josh Andler -
Joshua A. Andler -
Krzysztof Kosiński -
MenTaLguY -
Ted Gould