Re: Regarding Nautilus scripts
- From: Dave Camp <dave ximian com>
- To: Eugenia Loli-Queru <eloli hotmail com>
- Cc: nautilus-list gnome org, desktop-devel-list gnome org
- Subject: Re: Regarding Nautilus scripts
- Date: 08 Jun 2003 00:22:56 -0400
On Sat, 2003-06-07 at 23:40, Eugenia Loli-Queru wrote:
> > 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?
Bonobo context menu location is a different thread that we can discuss
seperately.
> 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?
No, those were not the scripts I was referring to. Any individual
features provided by scripts can be considered separately to decide
whether they appeal to a great enough subset of users to warrant being
in the main distribution. We can also separately decide where they
belong in a final product-ready UI.
Nautilus scripts are not intended as a way to build products. They are
specifically designed to be a quick way for power users to implement
features without needing to make them product-ready.
> These are not problems. These are extensions that extend functionality. They
> are not symptoms of anything. They are utilities to extent the
> functionality.
Yep.
> 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.
OK.
-dave
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]