Re: [Nautilus-list] script w/ mime handling
- From: Darin Adler <darin bentspoon com>
- To: Jonathan Blandford <jrb redhat com>, John Sullivan <sullivan eazel com>
- Cc: Tuomas Kuosmanen <tigert ximian com>, Nautilus <nautilus-list lists eazel com>
- Subject: Re: [Nautilus-list] script w/ mime handling
- Date: Wed, 17 Oct 2001 09:30:29 -0700
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.
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.
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.
--- Darin wanders off topic ---
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.
-- Darin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]