Re: Regarding Nautilus scripts
- From: "Eugenia Loli-Queru" <eloli hotmail com>
- To: <nautilus-list gnome org>, <desktop-devel-list gnome org>
- Subject: Re: Regarding Nautilus scripts
- Date: Sat, 7 Jun 2003 20:40:31 -0700
> Throwing together a nautilus script is much easier than writing
> nautilus code.
Thank you for mentioning this. Because this is where your problem lies with
addons I think.
You believe that people will need to write "nautilus code". This is not the
case. All you need is a simple API to define some information-passing and
that's all. You saw the Tracker API right? A few lines of code!
The user does _not_ have to know nautilus inside information. An addon is
nothing but an individual app, with only difference that it takes the
arguments that it needs from the nautilus API and _if_ necessary (like in an
File Selection addon), it will send information back to nautilus. Nothing
else about nautilus is needed to be known by the addon programmer.
> We do have an "addon api". Context menus can be added using bonobo
> objects. They currently show up in the toplevel context menu. They can
> be written in any language with bonobo support, which includes C and
> python among other things (the boilerplate for python code is around 10
> lines of code and twenty or so lines of .server file).
Good. Why can't this addon replace or co-exist with the Scripts then instead
of clogging the toplevel context menu?
And what these objects can do except placing themselves in that menu and get
a few arguments? Are the current API as flexible that can launch addons in
the way I described in my previous emails?
> One plan we've been kicking around is to hide the scripts menu if you
> don't have any scripts defined. This will reduce its discoverability
> even more, but will prevent it from getting in the way of people that
> don't care about it.
Indeed, this might be better if you don't plan to ship any scripts by
default.
> There were a number of scripts on g-scripts.sf.net that were clearly
> workarounds for bigger problems in gnome. We need to solve the problems
> there, not the symptoms.
Like what? a grep? an mp3 attribute editor? a file selector? a dos2unix?
ToUpper/ToLower?
These are not problems. These are extensions that extend functionality. They
are not symptoms of anything. They are utilities to extent the
functionality.
The g-scripts scripts might be designed to solve some symptoms, I don't
know. But my proposal here is about extending functionality, not solving any
symptoms. Even in year 2050 people will need to search for a word in the
content of a text file.
Regards,
Eugenia
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]