Re: [Nautilus-list] script w/ mime handling

[Jonathan Blandford <jrb redhat com>]

Darin Adler <darin bentspoon com> writes:

> on 10/17/01 8:52 AM, Jonathan Blandford at jrb redhat com wrote:
> 
> > John Sullivan <sullivan eazel com> writes:
> > 
> >> (1) It puts the burden on every user (or the installer program if there is
> >> one) to put each script in the right place. This is much more error-prone
> >> than if the script just "does the right thing" in the Scripts folder.
> > 
> > I don't think this is any harder than the rest of the rigmarole involved
> > with installing stuff on a modern system.  With some luck, the user will
> > get scripts with an rpm/deb.  We can write a script manager should we
> > get to that point.
> 
> If we want to install scripts with a packaging system, then we ought to
> change where Nautilus looks for scripts so it can find scripts places other
> than the user's home directory. The current feature is suitable for
> customization by the user, but not for scripts that are part of installed
> packages.

Yeah -- system installed scripts would definitely be a good thing.  That
way packages can install handlers for their mime-type.

> Anyway, if someone wants to implement the MIME type feature, we have to
> decide whether we want to use a directory structure or some kind of syntax
> inside the script to determine which scripts show up for each file.
> 
> If we use a directory structure, we don't have the start of something that
> can allow us to add other attributes to scripts. For example, once you have
> a script that applies to only certain kinds of items, you might also want a
> script that can have other attributes, like a check mark in the menu or
> something like that.
> 
> On the other hand, if we use some kind of syntax inside the scripts, we have
> to open each script to read this information and keep some kind of table
> inside Nautilus. And it will make the current script system, which works
> with any kind of executable, more specific to scripts as opposed to compiled
> binaries.

I don't think the first way is quite right.

> Maybe there are other pros and cons to these two schemes, but in either
> case, I think the first thing we need is someone who wants to implement the
> feature.

I would tentatively volunteer to look at it, and have been thinking a
lot about it.  However, I don't think I'll get a chance in the short
term, and would like to see 1.0.5 out first, and the branch occur.

> In any case, while it is fun to discuss new features, it's depressing to not
> have anyone helping me figure out the speed crisis so we can get 1.0.5 out
> the door and get gnome 2 porting underway. A major problem is that I don't
> see the slowness on my own machine.

That's my problem too -- it just works fine (TM) for me.  Unfortunately,
Alex is out of town (and out of contact) this whole week.  He might know
what's going on the best.  I can prod him when he gets back. (-:

-Jonathan