Re: Nautilus, metadata and extendet attributes



El lun, 02-02-2004 a las 11:30, Olaf Frączyk escribió:

> 
> OK. I personally agree here. I want "pure" extensions solution (may be
> as option for user to choose).
> > If users have associated Windows executable files with WINE, for
> > example, wine will run files whether they have extensions or not, as
> > long as they are PE (portable executable) files.  Users can then receive
> > something masquerading as a picture, but upon run, discover that their
> > files are gone.  That the risk is 1-in-100000 does not matter.
> If you associate only "exe" files, you have no risk.

Wrong.  You do *not* associate EXE files.  In Nautilus, you associate
MIME types, which are application/x-ms-dos-executable for Nautilus 2.4. 
I just removed the EXE extension from a file, and it opened with wine
fine (winamp.exe, if you care to know).

The problem is that you're looking at this with an "extension"
mindset.    This is not windows.  You don't associate apps with
extensions.  You associate file types with apps.  The extension
ultimately doesn't matter, and it won't matter because Nautilus does
sniffing.  The correct thing isn't removing sniffing.  The correct thing
is stop relying on extensions.

> If I have 500 .bmp and 500 .jpg files (eg. bmp - original, jpg -
> transformed) then extension is the easiest way for me to open the file I
> wanted. Or copy. Have you ever tried to sort files (without extensions)
> by type using midnight commander?

You get to keep the extensions for as long as you want (if you live up
to a hundred years, you can still have them).  You can slap any
extensions on any file you wish, and have MC work just as it works
today.  

Nevertheless, we already discussed the fact that each file will have its
own MIME type, and you can expect regular applications to use that
information to sort files and schtuff.

The whole point of this thing is to allow we who don't want to rely on
extensions to live well.  It's not meant to affect users who want to
keep the (wrong design decision) extensions.

I get the sense that you either didn't read the entire text of the
proposal, or didn't digest the implications of it.

>  :) And why I use mc instead of
> nautilus? Because it is fast, really fast. I don't want to waste 40
> seconds for waiting on directory listing if I can get it in 1 second.

Then why are you discussing Nautilus issues regarding MIME types?  (you
just stated you use MC *instead* of Nautilus).  If it's raw speed,
Nautilus will never be as fast as MC, simply because Nautilus has much
more functionality, and period.  Of course Nautilus could actually
afford you lots of speed, simply because it lets you be more efficient
than MC.

> > -- 
> > 	Manuel Amador (Rudd-O)
> > 	GPG key ID: 0xC1033CAD at keyserver.net
-- 
	Manuel Amador (Rudd-O)
	GPG key ID: 0xC1033CAD at keyserver.net

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente



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