Re: gmc associations



http://www.berlin-consortium.org/datatype.html

Has anyone considered using this library for determining MIME types 
and/or desktop icons?  I think the UNIX file command is, like, really 
cool; it would be great if we had some smart (fast too, of course :-) way 
to determine file types regardless of those meaningless file extensions.

I haven't seen this code, nor do I know how well it works...but I just 
stumbled across this blurb when reading about Berlin (which sounds really 
exciting, BTW! :-), and it sounded kind of applicable to what you were 
trying to do.  Is there already a library in GMC that does this (when 
speed is _not_ an issue :-)?

just a thought.

shane

On Sun, 27 Dec 1998, Miguel de Icaza wrote:

> 
> > how do you associate an application with a file type so when you double
> > click on an mp3 or something the player comes up?
> 
> Yes, this is from gnome-libs/devel-docs/mime-type-handling.txt:
> 
> > 
> > 1. MIME type handling in the GNOME desktop
> > ------------------------------------------
> > 
> > MIME types are using to distinguish what sort of operations and
> > attributes a file has.  The operations are usually things like: how to
> > open files of a given mime-type, how to view them, what icon is used
> > to display it and so on.
> > 
> > Besides the MIME types, in GNOME, the metadata system is used to
> > provide information in a per-file basis (for example, to override the
> > defaults of the mime-type). 
> > 
> > GNOME uses a number of techniques depending on the speed requirements
> > to figure out what the MIME type of a file is.  It is possible to get
> > the mime-type by only using the filename or if speed is not important,
> > by checking the actual file contents (for more information look at the
> > gnome-mime.h header file and the accompanying documentation).
> > 
> > There are ways in GNOME to fetch the values bound to a mime-type with
> > the routines provided in gnome-mime-info.c.
> > 
> > 
> > 2. Mapping a filename to a MIME type
> > ------------------------------------      
> > 
> > To make the GNOME desktop aware of a new MIME type it is necessary to
> > install a file with the extension .mime in the $gnome/share/mime-info
> > directory or from the ~/.gnome/mime-info directory.
> > 
> > The format is the following:
> > 
> > mime-type-name
> > 	  ext[,priority]: ext1 ext2 ext3
> > 	  ext[,priority]: ext4
> > 	  regex[,priority]: regex1
> > 	  regex[,priority]: regex2
> > 
> > where "mime-type-name" is a valid MIME type.  For example
> > "text/plain". 
> > 
> > Multiple ext and regex entries can be provided for this mime-type.
> > Please note that the regex keyword only allows one regular expression
> > per line, while the ext keyword lets you list a number of extensions
> > in the same line.
> > 
> > The priority indicates the number of components that your extension
> > matches (the bigger the number, the better).  Right now, only
> > priorities 1 and 2 are supported.
> > 
> > This is required to distinguish the mime type correctly for situations
> > like "emacs.tar.gz", where the .gz could match the "compressed" rule,
> > while the real match should be for "tar.gz", so a "tar.gz" would have
> > a higher priority
> > 
> > For example, for a vCalendar application, this file would be
> > installed:
> > 
> > ------ calendar.mime  -------
> > application/v-calendar:
> > 	  ext: vcf
> > -----------------------------
> > 
> > 3. Adding keys to a MIME type
> > -----------------------------
> > 
> > To add keys to a mime-type, it is necessary to install a file with the
> > extension .keys in the $gnome/share/mime-info directory or from the
> > ~/.gnome/mime-info directory.
> > 
> > The file has the following format:
> > 
> > mime-type-match:
> > 	  [\[LANG\]]key=value
> > 
> > "mime-type-match" allows you to provide either a full mime-type, or a
> > glob expression, for example, you can list "image/gif" for making the
> > entries apply to the image/gif mime type or "image/*" if you want the
> > keys to apply to all of the images.
> > 
> > The [LANG] part is optional, and it used to provide internationalized
> > versions of any strings appearing in the value.
> > 
> > key is the key (a number of keys are standarized) and value is the
> > value bound to it.
> > 
> > For example, the GIMP could ship with this file:
> > 
> > ------ gimp.keys --------
> > image/*:
> > 	  open=gimp %f
> > 	  
> > image/x-xcf:
> > 	  icon-filename=/opt/gimp/share/xcf.png
> > -------------------------
> > 
> > This will make the GIMP the handler for the open action.  Files of
> > type xcf would use the filename pointed in the icon-filename key.
> > 
> > %f gets interpolated with the file name or the list of file names that
> > matched this mime-type.
> > 
> > As you can see, a .keys file does not need to provide all of the
> > values, it can just provide or override some of the actions.
> > 
> > Note that user defined bindings in .keys file will take precedence
> > over system installed files.
> > 
> > 
> > 4. Default keys
> > ---------------
> > 
> > The following keys are recognized in the GNOME desktop:
> > 
> >     key			action
> > ------------------------------------------------------------
> > 
> >     open		open the give file with this command.
> > 
> >     icon-filename	points to a filename with the icon
> > 			  that should be used to represent files 
> > 			  of this type
> > 
> >     view                Command to view the file contents.
> > 
> >     ascii-view          A command that should be used to do
> > 			  an ascii-rendering of the file.   Used as 
> > 			  a fallback by the filemanager if a "view"
> > 			  action does not exist.
> > 
> >     fm-open             file-manager open.  If present, the file
> > 			  manager will use this action instead of the
> > 			  value in open to perform this action (the 
> > 			  filemanager for example will open archive files
> > 			  as if they were directories by using the VFS).
> > 
> >     fm-view		file-manager view.  If present, invoking the
> > 			  view opertion on the file manager will use the
> > 			  value defined here instead of the value in
> > 			  "view".
> > 
> >     fm-ascii-view	Fallback operation for the file manager as
> > 			  well.
> > 
> > Those keys are also queried on the metadata (except in the cases where
> > the lookup would be too expensive). 
> > 
> > 5. Defining multiple actions
> > ----------------------------
> > 
> > Somtimes it is important to provide more than one "open" action.  To
> > do this, the keys should be specified in the following fashion (The
> > same applies to any other key that might need more than one option):
> > 
> > text/plain:
> > 	  open=command %f
> > 	  open.tag1.Do this and that=this-and-that %f
> > 	  open.tag2.Gzip it=gzip %f
> > 	  open.tag3.Mail it=mail %{Recipient} < %f
> > 
> > This will define a default action (which woudl invoke "command %f"),
> > and three extra open commands:
> >    
> >    "Do this and that"	-> this-and-that %f
> >    "Gzip it"		-> gzip %f
> >    "Mail it"		-> mail ${Recipient} < %f
> > 
> > Please notice that you have to add a "tag" to every "open" key.
> > 
> > 6. Localizing the texts for a tagged key
> > ----------------------------------------
> > 
> > The reason for using the tags, is that they are required to
> > distinguish the correct value for internationalization purposes, here
> > is how the above example would be translated to spanish:
> > 
> > text/plain:
> > 	  open=command %f
> > 	  open.tag1.Do this and that=this-and-that %f
> > 	  [es]open.tag1.Hacer esto y aquello=this and that %f
> > 	  open.tag2.Gzip it=gzip %f
> > 	  [es]open.tag2.Comprimir con gzip=gzip %f
> > 	  open.tag3.Mail it=mail %{Recipient} < %f
> > 	  [es]open.tag3.Enviarlo por correo=mail %{Recipient} < %f
> > 	  open.tag4.Example=exampl %f
> > 
> > To the application programmer, if the code is running with LANG=es, he
> > will get the following keys: "open", "open.tag1.Hacer esto y aquello",
> > "open.tag2.Comprimir con gzip", "open.tag3.Enviarlo por correo" and
> > "open.tag4.Example" 
> > 
> > If a translation entry were missing, he would get the general
> > definition for the default value (in the example above, I did not
> > translate the value for open.tag4.
> > 
> > 
> > Miguel de Icaza (miguel@gnu.org).
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
> 
> 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]