Re: MIME types, again ("Nautilus" ain't the answer)

An anti-GNOME rant, eh?  I'm always up to defend my favourite desktop
:-)

On Mon, Feb 07, 2005 at 09:19:48PM -0800, Karsten M. Self wrote:
> on Mon, Feb 07, 2005 at 11:07:26PM -0500, Adam Hooper ([email protected]) wrote:
> > You can run Nautilus from within KDE, can't you? (Not ideal, I know, but
> > it's easy and it'll work.) If it refuses to open, maybe try with the
> > --no-desktop option.
> 
> I run WindowMaker, and find when running Nautilus:
> 
>   - I get a desktop filled with icons, etc.

...Which is why you run Nautilus with the --no-desktop option, just as
Adam Hooper suggested.  It's OK to complain about things, it's very
natural to have negative feelings about certain programs, but when you
won't even try perfectly valid solutions given by other people on the
mailing list, I don't really know what to tell you.

>   - My keybindings are trashed.

Presumably that's just a byproduct of your above point.  And in that
case, --no-desktop will also prevent that.  If not, I don't really know
what to tell you.

>   - Other random breakage, depending on the level of cerebral-fecal
>     impaction of the GNOME team this week.

Ah, so you've sunk to the level of flaming GNOME developers.
Interesting.

> Nautilus is *not* a simple file manager.  It's a poorly-scoped project
> which incorporates features of both a file manager *and* a desktop
> manager.  It's a classic example of design fuckwittedness within the
> GNOME team, as this design scoping means one *cannot* use Nautilus
> outside a GNOME-only environment.  By contrast, other FMs (Konqueror,
> gentoo (the FM, not the distro), GNUStep's file manager, etc., _can_ be
> effectively run outside their "native" environments.  While some people
> will gripe over the library requirements of some of these, at least a
> user doesn't find their desktop invaded by aliens for just trying a
> fscking application.

The choice is yours.  That's why we are Linux, BSD, etc. users -- we
don't feel we have enough of a choice with other environments.  If you
don't like the workings of the GNOME development team, no one's making
you use their desktop.  The GNOME team hasn't planned some ultimate
cat-stroking, world-domination plan, nor are they forcing people to use 
Nautilus, Galeon, etc. in a GNOME-only environment.

If all this is about Nautilus's drawing of the desktop when invoked
without any options, that issue has already been addressed by Adam and
myself.  But I do agree (and this is probably the only part of your
whole e-mail that I do agree with) that Nautilus should be "smart" and
rather than having a --no-desktop option, it should start without the
desktop by default and have a --desktop option instead.

As do your arguments, the rest of your e-mail gradually progresses
towards purer and purer flamebait...

> For all of that, Nautilus remains:
> 
>   - Slow.

What are you basing that on?  Nautilus 1.0 was slow and eye-candy
filled, and its speed has improved tremendously since then, at least for
me.  It practically starts instantly, and it's very zippy file manager
for me.

>   - Underfeatured -- MC does more, absent "oh, you need a wind-up,
>     candy-striped, squirrel-driven steamroller for _that_ functionality"
>     add-ons.

IMHO, Nautilus does all it should, no more, no less.  It allows the user
to manage files.  What features does it have that you'd need?  I look at
a file manager like Konqueror and I think "bloated!"  At least when I'm
in Nautilus I feel like I'm in control, and it's great for basic file
management.  I personally prefer the console for most of my file
management personally, but since the introduction of spatial Nautilus,
I've found myself using a graphical file manager for the first time in
years.  It just "feels" so smooth and aesthetic to me.

> Etc.

Please elaborate.  "Etc" may be quite a clear indication of Nautilus's
additional issues in your mind, but it really doesn't express your true
opinion very well.  So please, go on...

> I'm with OP:  if Galeon *insists* on using GNOME misfeatures for storage
> of configuration data, provide UI access to same from within Galeon.
> 
> If this can't be done, I'd strongly suggest reconsidering widget sets
> and pulling from elsewhere where possible.
>

I believe the developers are quite happy with their product in the
making, and there are many people who are very happy with the transition
between 1.2 and 1.3.x.  If you loved 1.2.x so dearly, why don't you fork
it and start your own web browser?  The code is there, and I'm sure you
could resurrect it if you tried.  You'd probably get further than you
would by just bitching about 1.3.

> > > I thought I'd come to terms with the fact that Galeon/Gnome don't use
> > > mime.types etc, but once again, if you know how things _should_ work
> > > and are trying to run applications from Gnome, KDE, _and_ real Unix,
> > > it's just unbelievably frustrating to find that in order to change a
> > > file association you have to configure 3 different systems.
> > 
> > Freedesktop has a page set up for a unified system:
> > http://freedesktop.org/wiki/Standards_2fmime_2dactions_2dspec
> > 
> > Out of curiosity, what's the "real" Unix way of handling file
> > associations?
> 
> /etc/mime.types

/etc/mime.types defines the definitions, yes, but /etc/mailcap is where
the actual applications are defined.

> > > Wouldn't it be possible for Galeon to have a menu item that let you
> > > go straight to Gnome's "mime.types" system?  It would even be
> > > possible to only display this menu item if it were determined that
> > > KDE was running.
> > 
> > Yes, it would be possible. But who's going to write it? As far as I
> > know, all Galeon developers use GNOME.
> 
> Pity, that.

Here's some light "bedtime reading" for you all: [1] and [2].  [1] tells
you how the new Freedesktop MIME system works, and [2] tells you how
these programs add MIME types to the database.  Rather than using
/etc/mailcap, they use some very nice and easy-to-understand XML files
that define basically the same stuff that /etc/mime.types and
/etc/mailcap did, but with several advantages:

- Obviously it is now a Freedesktop specification, and it's meant to be
  *used*.  And that's all the GNOME team is doing:  following standards.
  If you disagree with those standards, which will eventually be adopted
  by the KDE team, and already has been adopted by GNOME and ROX (and
  probably others).  I for one hope that the "real UNIX method" (I
  prefer "old" or "legacy" method) is eventually deprecated in favour of
  the freedesktop.org standard.

- .desktop files will be allowed to be defined as a "can-edit-with"
  option.  This has many clear advantages, but probably most
  importantly, if the .desktop file contains "StartupNotify=true" then
  in theory (I say in theory because Nautilus/Galeon don't do this 
  properly  yet, but should) the user should get a nice busy cursor as
  the program is invoked as an "open with."  You may argue that "KDE
  already does this!"  But KDE's method is much more broken now IMHO --
  first of all they don't use the freedesktop MIME standard yet, and
  second, they *always* give an app startup notification, which means
  that legacy apps will have a busy cursor that continues to be busy
  even after the legacy app has started.

> Peace.

I have a feeling that this is actually "war" ;-)

References:
[1] http://www.freedesktop.org/Standards/shared-mime-info-spec
[2] http://www.freedesktop.org/wiki/Standards_2fAddingMIMETutor

-- 
Your fortune for the day:
Beauty and harmony are as necessary to you as the very breath of life.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click