Icon naming spec: generic binary MIME type icon?

[Rodney Dawes]

On Sun, 2008-12-07 at 13:52 +0200, Ville Skyttä wrote:
> On Sunday 07 December 2008, Rodney Dawes wrote:
> > On Sat, 2008-12-06 at 01:05 +0100, Jakob Petsovits wrote:
> > > Yes, of course. I'm aware that gnome-icon-theme has little relevance to
> > > spec issues, and did not intend to imply any connection, just that it's
> > > not currently possible to use an application-octet-stream icon while
> > > assuming that it will actually be present.
> >
> > Well, the point of the spec is to have generic fallbacks, and so you can
> > query for things which aren't necessarily going to be in an icon theme.
> > We now also have generic icon names specifiable in the shared-mime-info
> > data, and in the Shared MIME spec.
> 
> Yes, this is exactly what prompted me to start this thread: shared-mime-info 
> apparently has chosen to use the text-x-generic generic icon at least for 
> some things for which there's no better standard generic icon available in 
> the icon naming spec, even if the files of the MIME type are binary files, 
> not text?

Well, "binary" is not a particularly useful classification. Neither is
"application" really. For certain file types it definitely doesn't make
sense to be using text-x-generic. And none of the icons in the current
spec may make sense. In the cases where they don't, we really need an
appropriate classification for those types, so that we can create a
generic icon for that classification, and not generic "random data"
icons, which would be entirely useless to a user.

> For example, the generic icon for application/x-pkcs12 in shared-mime-info is 
> text-x-generic which makes no sense to me.

I'm not sure that this one doesn't make sense. pkcs certificates are
just a long string of characters, with line breaks, no?

> Maybe these (now that I look into the XML, there actually is just a few of 
> them) are just bugs in shared-mime-info and non-text files for which there's 
> no better generic icon name available in the icon naming spec's standard mime 
> type icons list should not have any generic-icon specified whatsoever?
> 
> Or alternatively, an icon for generic binary files could be added in the 
> standard mime type icons list so that could be used instead of leaving out 
> generic-icon altogether in shared-mime-info (or using something (IMO) clearly 
> wrong such as text-x-generic for them in it, or using something like 
> application-octet-stream in it which is not in the standard mime type icon 
> list and thus cannot be trusted to be available)?

Yes, if there are types that existing generic icons in the spec don't
cover, we need to classify those types appropriately and come up with
appropriate names for them. Just "binary" isn't very useful (technically
speaking, everything in the computer is binary). :)

-- Rodney