After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 170699 - Icons should have the ability to cover an entire mime-type/filetype
Icons should have the ability to cover an entire mime-type/filetype
Status: RESOLVED WONTFIX
Product: gnome-vfs
Classification: Deprecated
Component: Other
cvs (head)
Other All
: Normal enhancement
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
Depends on:
Blocks:
 
 
Reported: 2005-03-17 17:05 UTC by Brian Kerley
Modified: 2008-09-06 18:54 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Brian Kerley 2005-03-17 17:05:13 UTC
It would be nice if instead of having to have icons for every filetype such as
application-video-avi, application-video-mpeg, etc., if instead you could have
one icon for application-video and have it be applied to all of those filetypes.
 I initially filed this under gnome-mime-data, but then was informed this is
more of a gnome-vfs issue.
Comment 1 Christian Neumair 2005-05-09 18:42:27 UTC
Thanks for your bug report!
Nowadays we use shared-mime-info [1] as our source of MIME information
Shouldn't this work now that xdgmime has MIME subclassing in place?

Two issues:
1) There should be a global parent class which subclasses all video MIME
types(application/x-video or such). I don't think there yet exists such a parent
class. This is shared-mime-info's job.
2) GNOME-VFS should support having an icon for a whole "MIME group". In this
case, "video", since many movie MIME types are "video/x-sgi-movie", "video/foo".
Is this already possible?

[1] http://freedesktop.org/Software/shared-mime-info
Comment 2 Christian Neumair 2005-05-09 18:45:28 UTC
FYI, I've filed 1) under freedesktop.org bugzilla [1].

[1] https://bugs.freedesktop.org/show_bug.cgi?id=3250
Comment 3 Brian Kerley 2005-05-10 14:09:20 UTC
Well, it _is_ impemented in a way.  In an .theme file for the icons, if you
remove the "inherits" line, Gnome will use the very high-level icons that would
cover an entire MIME type if none of the specific ones (i.e .mp3, .ogg, .wma,
etc) exist.  What I am seeing happens you have specified an upper level MIME
type, but you don't have one for all the MIME types.  For example, I may have an
icon that covers the "audio" MIME types, but I don't have one that would cover
.pdf, .zip, .tar, etc.  These don't fit into one of the MIME classes perse, but
instead they are something like "gnome-application-x-pdf", etc.  So to correct
this, you would use the "inherits" in your .theme file for the icon set.  When
Gnome encounters an audio file, mp3 for instance, it sees that there is a
specific mp3 icon in the inherited icon set and uses this instead of the icon
that was already specified to cover _all_ the audio MIME types.  

What would be nice is if Gnome could first check the icon theme.  It would then
apply the appropriate icons, and then it would start looking in the inherited
icon set for any MIME types whose higher level MIME icon has not been assigned
yet.  

Here would be an example of the order it could go:
See .mp3 file 
look in current icon set for .mp3 icon
if none are found, look for the audio class MIME icon 
     if that exists, then it is done, 
     else, look in the inherited icon set for an .mp3 icon
          if the .mp3 icon in the inherited set exists, then apply it
          else, look in the inherited set for the audio class icon
              if is found, apply it
              else, use the "unknown" icon"
              end if
          end if
     end if
end if
Comment 4 John Pye 2005-06-20 11:13:09 UTC
Hi all 
Well this seems to be the best place on the whole internet to ask my problem at
the moment... so here goes... let me know if you'd prefer I filed a new bug/rfe.

I have been trying to package up an application which defines its own documents
filetype, *.mso. These documents are easily editable as text, so it makes sense
do define their mime type as text/x-mso.

I want to be able to define an icon for these documents. I've managed to install
the icon in the location
/usr/share/icons/gnome/48x48/mimetypes/gnome-mime-text-x-mso.png and also
/usr/share/pixmaps/emso.png but instead of my lovely icons being displayed, the
default GNOME 'text' icon shows up, which has a plain 'page' look but includes a
thumbnail of the first few characters of the first few lines.

Looking at Brian's comments above, it seems that this is deliberate: *fallback*
icons will always be used if present in the current 'icon set' (I take that to
mean for example 'hicolor' or Bluecurve).

Is there a way that I can specify this icon without adding copies of my icon to
all of the installed 'icon sets'? Or should I just relax and accept that the
'fallback' icon is what the user actually *wants* ?

Cheers,
JP
Comment 5 Christian Neumair 2005-12-01 19:43:43 UTC
John: You should install it in
/usr/share/icons/hicolor/48x48/mimetypes/text/x-mso.png. Before your files show
up as "text/x-mso", you'll have to specify the MIME type according to the
freedesktop.org MIME spec, installing a file like

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/Standards/shared-mime-info">
  <mime-type type="text/x-mso">
    <sub-class-of type="text/plain"/>
    <comment>MSO document</comment>
    <glob pattern="*.mso"/>
    <magic priority="50">
<!-- specify typical contents of the file accoding to the spec !-->
    </magic>
  </mime-type>
</mime-info>

to /usr/share/mime/packages/mso.xml, running update-mime-database after
installation. Sorry for the late response!
Comment 6 Rodney Dawes 2006-07-29 11:41:28 UTC
Please do not install MIME type icons into the theme with standard names. We are working on a solution for applications needing to provide MIME icons, in the icon and mime specifications on freedesktop.org, but the implementation isn't available yet.
Comment 7 André Klapper 2008-09-06 18:54:38 UTC
gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome.

If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs.

@Bugzilla mail recipients: query for
      gnome-vfs-mass-close
to get rid of this notification noise all together.


General further information: http://en.wikipedia.org/wiki/GVFS 
Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html