Re: Regarding Nautilus scripts

["Eugenia Loli-Queru" <eloli hotmail com>]

> > Then why implement it at all?
>
> Because users can't add C code to nautilus. The intent is to let you
> write scripts that do some site-specific or user-specific task.

Yes, but you are under-utilizing scripts today. You don't "market" them
enough. There is a discoverability issue.
And at the end of the day, pure scripts are nowhere as powerful or
extensible or robust as addons are. You said it yourself.

There is an interesting issue here with your strategy: You prefer to keep
scripts around because "some" user will need it to write a _very_
specific/custom bash script for his own and only own purposes and this will
probably will please what? 1% of the nautilus users? (and chances are that
such a user knows some C anyway and probably can create the same script
without the need of Nautilus)
And you don't want to make the jump to create an addon API that will help
_everyone_ who uses nautilus by having 4-5 default extremely useful addons
there, and I can think of at least 10 more that I would personally find also
useful for everyone.

There is another issue here, even bigger: The Nautilus developers have not
even found a single script that is worth shipping. It is like saying "well,
we implemented the script thingie, but we don't know what it would be useful
for, so we won't ship a sample with it, if the user wants to do somethng
with it, great, if not, great as well". For me, this is terrible thinking.
As a user, when I see an EMPTY menu all the time, never filled up with any
options, is just a reduntant menu. It is just wrong.

If you don't wanna hear me out about an addons api, at least please do
something about the existing scripts menu. Either take it out or ship some
scripts with it. The way it is now, it is just unacceptable and
unprofessional IMHO.

> I never would have bothered making a mime-type for the terminal
> if we had shipped a script to do it. another example
>is if we implemented a script to run things as root we
> might never implement a proper authentication infrastructure.

Then I am sorry to say this, but this sounds like problematic management of
the project rather than an addon issue in itself.
Personally, I don't believe it will create a problem.

>As for your grep tool - do you not think it would be better as a stand
alone program?

Definately not. The whole power of grep-as-an-addon is to do this:
1. select files/dirs on a nautilus window
2. Right click, choose the visual grep addon
3. A small window comes up. In the focused text input field type something,
press enter.
4. You immediately get results for what you searched in the files/dirs you
selected *only*
5. Double click any of the results to load the file (e.g. a text file will
open on gedit)

The key here is this: "Do this or that, for the *selected* files and dirs on
my current file manager window".
This is integration. This is code and information resuse (you get a lot of
info that each addons need via the API). This is an extensible and clean
file manager. This is a powerful, integrated Gnome.

By creating little utility  file manager-related) applications here and
there and then clogging the application menu with them, will get you to the
KDE bloat in a year or two and you will have achieved a Zero in integration,
elegance, power. The people responsible for Nautilus shouldw have to think
big, instead of "my 5-hour nautilus hacking". They will have to think the
gnome project as a whole when you take such design decisions.

BTW, in my previous list I forgot another great addon: file selection (via
easy gui options and/or regex and/or through grep itself). ;-)

Rgds,
Eugenia