Re: Regarding Nautilus scripts



> On Fri, Jun 06, 2003 at 05:54:29PM -0700, Eugenia Loli-Queru wrote:
> > I was thinking the other day that this very nice addition of Nautilus,
its
> > scripts found on context menu, are completely going to waste, because
Gnome
> > is shiping not even a single script by default.
> >
> Havoc wrote:
> The thing is that if we thought some functinality would be good by
> default, we probably wouldn't implement it as a script. ;-)

Then why implement it at all? The fact that you have a whole submenu there
with nothing in it and with no apparent usage is a mistake on its own. IMHO,
you will have to either populate this submenu with 1-2 items as a sample
functionality for important stuff (e.g. open terminal here), or don't have
it at all.

> Scripts are inherently kind of a hack, writing real code is going to
> have a nicer UI and be more robust. The virtue of scripts is that
> users can easily write their own.

I understand that scripts are easier to write, but the current situation has
a huge discoverability issue.

My personal experience with BeOS (which used this kind of usage via addons)
has shown that there are only 8-10 addons that people are generally after
(the list I mentioned yesterday, plus some "bulk rename" functionality). As
you also said, addons are way more robust. And for a C developer, really a
trivial thing to write if the API is well done.
So, if the issue here is "we don't ship scripts because they are hacks", why
do you include the feature altogether? Switch into an addon architecture (I
provided a link for OpenTracker's API to get ideas), write 2-3 addons by
default as samples, move under its submenu the items that they should not be
under the root context menu (so you add in overall clarity too)...

> Mark wrote;
>> a graphical Grep (programmers willlike this),
>I'd say that programmers are more likely to want to grep at a console

I highly disagree and I believe you state this because you never used a good
visual grep tool. Gnome is here to make strides on the desktop, and to do
that, it should provide such innovation that will _even_ make these 50-year
old unix heads to feel comfortable and give them a reason to use gnome in
the first place. And at the same time, introduce the power of grep to the
young/newbie users. I am not suggesting to GUI-ify command lines, this would
be stupid. But having such *addons* for things like grep/rename/convert text
files/touch, it is just so much easier for everybody! Why? Because this is
what you do with Bash and it is what generally makes you open a terminal in
the first place!!! Think about it. Adding that kind of  functionality on
your gui file manager is only normal, natural evolution over bash!
Otherwise, we will never get over the command line! Again, I am not saying
to gui-ify command line apps. This would be utterly stupid and reduntant.
But for some specific stuff, it is needed. If it done right, it can work in
favor of Nautilus and Gnome.

Having used gui grep with Tracker as an addon and on MacOSX (there are... 3
visual grep apps for OSX, my screenshot:
http://www.osnews.com/img/3721/mac.jpg), it just doesn't compare in
functionality! It's just easy to use, it only searches to the files you have
selected in the file manager (and directories), it offers you the result as
clickable files (that load the right app to open them) etc. It is just plain
useful and more importantly: FASTER to deal with. This reason alone would
convert even the most adamant unix head to use it instead the command line
version.

And this is the very reason the "Scripts/addon" idea was created for
Nautilus. I know this because I do know Pavel (the guy who did it for beos,
nautilus and who now works at Apple). By not using it, neither endorsing it,
I believe Nautilus itself as a project is losing in functionality, natural
evolution over bash on specific command line functionality, and with it,
Gnome itself.

I am sorry that I had to write 3 paragraphs for grep itself, while there is
a whole universe of addons that  I could present here and can extend
functionality *without* adding bloat! It just that was the one that striked
me most. Grep is definately not the most important addon.

>Maybe we need a New-> and/or Send to-> item in the context menu.

You certainly need a "New ->" on Nautilus (currently you have there "new" 4
items clonging the root menu), but you do not need the "Send To->" menu.
Windows has to do it this way because it doesn't have an addon architecture.
All the Send-To stuff should go under "Addon" (after you discontinue
"Scripts" and "Addons" is created that is ;).

>> Other cool stuff to consider: automatic tar.gzip of the file/dir(s)
selected
>> in the file manager or in the desktop,
>File roller's context menu plugins do this already..

Yes I know that, I mentioned it. but as I explained, it does that in the
root menu of Nautilus, and that is _dreadful_ for a clean and consistent UI
throughout machines. I certainly don't want "a Konqueror/KDE" on my Gnome. I
prefer clean solutions.

>I think that scripts is a useful feature, but IMHO shipping scripts by
>default with gnome would encourage us to work around problems with
>nautilus/gnome instead of fixing them..

I don't quite understand this. Please fill me up as to what problems are
exist regarding Scripts. And why shipping 1-2 scripts is actually a hack.
And if it is a hack, why don't we switch to the addon architecture which
would support GUI apps (and command line apps)?

Regards,
Eugenia

Appendix:
Ideas that can extend functionality without adding bloat, as users can only
include the ones they need in their "addon" submemenu (some with a simple
gui, some don't). These addons mostly work for the selected folder or files.
* Open Terminal Here
* Convert to ogg
* Background image
* Visual grep
* Touch
* Send to email/fax/printer/etc
* FTP-it
* mp3 attribute editor for selected mp3
* File Roller's addons for compression
* Unix2Dos/Dos2Unix
* Run
* ToUpper/ToLower
and much more.... use your imagination, add functionality, cut
bloat/clutter. :D



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]