Why don't GNOME/KDE/others use a seperate icon filetype?

[JillSwift]

I hear what you're saying, Jill. I would wonder if the graphic artist would know about it though. I don't think I'd be too far off thinking that most icon artists now probably: create each icon individual, save that icon (after navigating several folders), and then move that folder after creating the appropriate directories... It is common now for companies to provide artists with environments that enable creativity as artists are either poor at it or are just not concerned about the peculiarities that are needed to do so.

I think you're underestimating artists. Any good artist gets to know the medium, and it's not like folks are hiding the tools that make it all easier.

On the other hand, making a new format and the tools necessary to editing that format produces exactly the same situation. Only one factor worse, it's not obvious how to edit the new format. GIMP and to a lesser degree InkScape are commonly installed because they are broadly useful. Editing a png or svg is then a matter of a double-click. But something as specific as an icon specialty file editor... well, you'd have to learn about that before you could even get started.

[Fzang]

You're contradicting yourself. If you want the extra layer, which you'll get if you use a new or existing mipmap format, you'll need an icon library. No way around it. You need some way of opening the icon file and extracting the bitmap you want. You need libs to open image files as well, by the way (look at all the libpng-*, libjpeg-*, etc. packages), so using a different library wouldn't add significant overhead other than the process of extracting the correct bitmap from your mipmap icon. I have no idea how computationally expensive it is to render vector graphics.

Sorry, I must've expressed myself in an unclear manner. With icon library I mean the libraries that bind them together, such as .dll and .icl on windows, not system libraries.

And besides, what makes the OP think you need multiple files for icons? You can use any size image (AFAIK with no or no significant restriction) as your icon source, and Gnome, etc., will scale it as appropriate.

I'm sorry, but I think you've missed the whole art/design thing. Go read up here http://psd.tutsplus.com/articles/7-p...e-icon-design/ or something...

[kirsis]

kirsis, I'm thinking you haven't read the thread.

My apologies, I indeed glanced over a few posts only. From the first post I got the impression that the OP is advocating the use of a special-purpose icon library format (not necessarily .ico).

As for the actual issue, I suppose that should be up to artists. As the icon end user, I don't have to deal with the filesystem nor do I want to. It works for me. If the artists prefer to pack em up, then by all means.

Some people have mentioned that a packed icon library would create unnecessary overhead. This is not necessarily true. The tar format is not compressed, so there is barely any overhead in extracting the icons (no point in gzipping, for example, the icon archive since the images are already in an optimized format).

Keep in mind that icons in a tar archive would be all stored in one place on the hdd and could be read in one fell swoop, wheras reading icons stored as seperate files might require the storage device to perform more operations to read em (seeking operations).

I'm no expert on storage devices, of course, but I believe that whatever small overhead there'd be from reading tar archives, would be offset by the possibility of reading all the icons in one read operation.

Also, GTK likely provides API functions for loading icons, so a change in the system shouldn't afect any existing apps.

To sum my opinion up - it's up to icon creators. End-users are unlikely to have good reasons to want a change in the way icons are stored.

[Mornedhel]

As for the actual issue, I suppose that should be up to artists. As the icon end user, I don't have to deal with the filesystem nor do I want to. It works for me. If the artists prefer to pack em up, then by all means.

It affects developers and end users too. *You* may not want to deal with the filesystem, but Linux is meant to be tinkerer-friendly.

Some people have mentioned that a packed icon library would create unnecessary overhead. This is not necessarily true. The tar format is not compressed, so there is barely any overhead in extracting the icons (no point in gzipping, for example, the icon archive since the images are already in an optimized format).

This is true. There is also no advantage to using a tar containing a hierarchy of folders, instead of manipulating the hierarchy directly.

Keep in mind that icons in a tar archive would be all stored in one place on the hdd and could be read in one fell swoop, wheras reading icons stored as seperate files might require the storage device to perform more operations to read em (seeking operations).

This is also true, but I can think of no situation where it might be useful to load at once all icons from a theme, or all icon sizes from an icon. Icons are typically fetched only when necessary. There is no point in creating a buffer and filling it with all your icons.

Also, GTK likely provides API functions for loading icons, so a change in the system shouldn't afect any existing apps.

Unfortunately, there are still apps out there that do not use the GTK API for everything. The way it is now, icons don't need to be packaged differently for other toolkits, too.

To sum my opinion up - it's up to icon creators. End-users are unlikely to have good reasons to want a change in the way icons are stored.

Icon creators won't care, developers will. Artists are just that : people with the creative skills to produce artistic works, for instance icons. If an artist happens to be a developer, good for him, but don't assume all artists are developers and vice-versa.

[kirsis]

It affects developers and end users too. *You* may not want to deal with the filesystem, but Linux is meant to be tinkerer-friendly.

Gnome may be meant to be tinker friendly, Linux is definitely all about being practical.

However, Gnome has never struck me as being very tinker friendly either; other aspects usually take precedence and sometimes eliminate the "tinker-friendly" aspect completely (hence its reputation as being less configurable than KDE).

Micromanaging icons is an activity that, I suspect, will be of interest to the absolute minority of users (not talking about installing icon themes here, which is something a lot of people do and is unrelated). In my opinion this absolute minority (of which the majority are likely icon artists) can be inconvenienced (managing packed icons is not any less tinker-friendly than managing a hierarchy in the file system) if that eases the job of those who create the icons.

This is true. There is also no advantage to using a tar containing a hierarchy of folders, instead of manipulating the hierarchy directly.

The sole advantage I can think of is that all the icons for a specific application can be replaced/moved/copied by replacing/moving/copying one file. Also, I don't suppose a folder hierarchy is necessary in TAR. I suspect a strict naming scheme would suffice.

This is also true, but I can think of no situation where it might be useful to load at once all icons from a theme, or all icon sizes from an icon. Icons are typically fetched only when necessary. There is no point in creating a buffer and filling it with all your icons.

True.

Unfortunately, there are still apps out there that do not use the GTK API for everything. The way it is now, icons don't need to be packaged differently for other toolkits, too.

Indeed. A change would require a change in the FreeDesktop specification and then there'd be a transition period where some apps would occasionally have missing icons.

This is a good reason not to change anything.

Icon creators won't care, developers will. Artists are just that : people with the creative skills to produce artistic works, for instance icons. If an artist happens to be a developer, good for him, but don't assume all artists are developers and vice-versa.

I don't know about the artists, but I don't see why developers would care much. Basically only the widget toolkits would need any changing, and I think the changes would be very minor. (as for apps that don't use their widget toolkit api to load icons - shame on them and maybe a change like this would encourage them to utilize their platform of choice properly).

So again - I can imagine only the icon creators being bothered about having to maintain a file hierarchy instead of a tar archive or vice-versa (no programming involved here). If they're not bothered, good. What we have now works very good.

[ceramicm]

On the other hand, making a new format and the tools necessary to editing that format produces exactly the same situation. Only one factor worse, it's not obvious how to edit the new format.

Why write a whole new decoder library... Why create a new editor for icon formats...

And I don't know what's meant with "special editor". It's only special because no one has made it yet.

I know the discussion has moved on past this a bit, but as far as .ico files go, I've never had any problems opening and editing them in GIMP--no new tools/libraries required.

[Mornedhel]

Gnome may be meant to be tinker friendly, Linux is definitely all about being practical.

However, Gnome has never struck me as being very tinker friendly either; other aspects usually take precedence and sometimes eliminate the "tinker-friendly" aspect completely (hence its reputation as being less configurable than KDE).

Micromanaging icons is an activity that, I suspect, will be of interest to the absolute minority of users (not talking about installing icon themes here, which is something a lot of people do and is unrelated). In my opinion this absolute minority (of which the majority are likely icon artists) can be inconvenienced (managing packed icons is not any less tinker-friendly than managing a hierarchy in the file system) if that eases the job of those who create the icons.

I don't think Gnome was ever meant to be tinker friendly, but Linux certainly was, and still is. Being tinker friendly is a good part of being practical : it means you have access not only to high-level applications, but low-level tools as well. (Gnome definitely deserves its reputation of being less configurable than KDE, although KDE could do with a little less configurability sometimes...)

I agree that micromanaging icons, as you put it, will be of interest to almost no one. However, with the current scheme of things, it remains available. In my opinion, changing the icon system to a tar or tar-like system doesn't add any functionality and removes some (however seldom used).

The sole advantage I can think of is that all the icons for a specific application can be replaced/moved/copied by replacing/moving/copying one file. Also, I don't suppose a folder hierarchy is necessary in TAR. I suspect a strict naming scheme would suffice.

A strict naming scheme would suffice, yes. It would also work instead of folder hierarchies, without bringing tar into the mix.

Moving all the icons for a specific application can still be achieved, with a folder hierarchy, simply by moving the top folder.

I don't know about the artists, but I don't see why developers would care much. Basically only the widget toolkits would need any changing, and I think the changes would be very minor. (as for apps that don't use their widget toolkit api to load icons - shame on them and maybe a change like this would encourage them to utilize their platform of choice properly).

Artists would probably not care too much because it's not their job to package the icon set, it's the distribution maintainer's (in theory). Furthermore, as someone else on this thread has pointed out, tools are available to automate this process, so artists really don't have to do any work (besides the actual designing of icons, obviously).

Although I never tried packaging an icon set nor have I designed one, so if any icon designer reads this thread, let me know if I'm speaking out of my posterior.

As for developers, you have to remember that not everyone out there uses GTK+ or Qt, nor do they want to. The other day I wrote a (very dumb) elisp function to display notifications when my media player (emacs -- that's right, my media player is emacs) starts playing a new track. The notification displays the album cover art, or the emacs icon if no cover is available. As it is now, all I had to do was display a PNG. I don't use a toolkit to display icons, because I don't have one.

One last thing. Currently there is a fallback system of sorts for icons. Applications come with their own icon, but icon sets can override them and use an icon that is more in harmony with the icon set's overall theme. I think the fact that it can be possible to have to look in several places for the correct icon means that adding a layer (looking inside the tar file) could start being a significant overhead. I don't know if it can be necessary to look in more than two places, but if it is, icon loading might be significantly slowed.

[Mark76]

Never mind the file format, how about someone gets to work producing an icon set that's less cartoony or less ripped off from OSX than most of the current ones?

[Xbehave]

Never mind the file format, how about someone gets to work producing an icon set that's less cartoony or less ripped off from OSX than most of the current ones?

Have a look here, personally i like oxygen!

I agree that micromanaging icons, as you put it, will be of interest to almost no one.

While I agree, one use immediately springs to mind, having a simple/hi contrast theme for small icons, but keep a nice detailed theme for larger ones, while you could produce a new theme for this just editing/renaming the files in your icon folders.

PNG for your common icon sizes = win
SVG for those places where the icon may need to be anysize = double win