Re: Icons and document-types

[Toshio Kuratomi <badger prtr-13 ucsc edu>]

On Thu, 23 Apr, 1998 at 11:54:00AM -0500, Miguel de Icaza set free these words:
> 
> > PS: Isn't that area under tight control of the gmc team/author
> > (M.d.I)?  I wander what Miguel thinks about it? 
> 
> It is not under tight control.  I am just waiting for the thread to
> come up with some consensus before coding anything.
> 
> Right now the file manager is using a file called mc.ext (for
> historical reasons) that provides actions based on: The file type (by
> using the file command and parsing the output), or the file name (by
> using regular expressions on the file name).  
> 
> Then a list of tags for each match is listed:  Some of them are
> reserved (Open, View, Drop, Icon, Include) and the rest are just
> included in a context-popup for the user to use.
> 
> In the future, I want to move away from this setup and use a
> mimelnk-like style setup:  First of all, instead of relying on the
> current output of the file command, I would like to use KDE's idea of
> having a magic file that maps the file contents to a mime-type and
> extend the existing magic file with user-defined and system-extended
> magic bits (ie, package drops /opt/gnome/lib/jpeg.mime file, and the
> file manager will auto-pick this).
> 
> Then, the existing mc.ext file, will use mime-types for this sort of
> action.
> 
What would you think of passing a file name into a library/service and having
it give you back all your tags/icons/etc?  That way the code for doing this
would be available for other fm's and programs?  It would also allow arbitrary
tags to be implemented in a single place (Behind the library interface) rather
than with each individual application. (ie: say some other program needs to
define several more programs to specify some state the file can be in.)

Mapping magic to mime-types might be useful inside of the library (As a way of
abstracting the type of file).  However, their needs to be a way of grabbing
user overrides as well -- Maybe an ordering like this:
    1) user file regex's
    2) system file regex's
    3) user magic
    4) system magic
    5) user extensions
    6) system extensions

That should specify precedence, but not necessarily processing (ie: regex's
should probably be processed in that order to grab a user match before a
system match but user magic can simply override any system magic for the same
file.)

By the way -- how efficient is regular expression usage?  Because I was
thinking specifying files as !.*bin/filename$! rather than full path could
make some configurations easier.  (But I figured that this could be
inefficient because searching for a specific file would have to attempt
matches with every regex....)

-Toshio
-- 
badger  \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~