Re: Regarding Nautilus scripts

[Ryan McDougall <ryan mcdougall telusplanet net>]

I would like to second that motion, but I must ask myself what can/do
the scripts really provide? I think its pretty clear that scripts,
regardless of context, represent complex tasks or interactions that
either cant, or dont need to be captured with existing gui elements.
>From my perspective "Task Based" designs are the way to go, so the
problem reduces to: What tasks do users [want to] do with Nautilus, that
isnt already incorporated into the existing gui?

Why arent they living up to their potential? Are the really a derth of
tasks users want to accomplish with Nautilus that they cant do with a
the gui? Are the features of Nautilus poorly exposed via external
interfaces, so that scripts cant even use Nautilus functionality? Or is
Gnome/Nautilus an immatures or poorly integrated platform? These are
weightier questions.

I think its clear that Scripts are a very natural means of integrating
CLI shells with GUI shells ( bash/nautilus ), since shells scrips are in
the shells language, but there major stumbling block is that cli shells
were never designed to work nicely with modern components such as
nautilus. Im working on a new shell with an API available to outside
processes, as a means to address the aging shell paradigm.

Aside: File Roller is brilliant stuff -- all my archiving problems
solved, all with Nautilus integration.
 
Some thoughts on complex tasks that dont have a nice gui: 

- I would truely like the ability to compile a source tar ball from
Nautilus. "Build Source" might run ./configure if its exists, then run
make. "Install from Built Source" would then switch to super user and
run make install.

- Almost all scripts will be media limited: there are very few tasks
left that dont depend on the media type.

- "Delete all Duplicates" is dangerous but doable using md5 checksums,
and some minimal AI.

- A very intersting idea might be "Send to this Machine" which might
attempt several means to open a secure channel to another internet
connected machine, possible using scp ( secure copy in ssh ).

- "Check Integrity" with a dialogue to prompt the user for an md5
checksum file. Good for internet downloads such as ISOs.

- "New Term Here" is a perennial favorite.

- "Send to Email" seems doable with certain email clients.

2 cents.

Cheers,
Ryan



On Fri, 2003-06-06 at 18:54, Eugenia Loli-Queru wrote:
> Hello all,
> 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. When users don't see at
> least 1-2 useful scripts there by default, they just don't bother of finding
> out more about how the thing works or why it could be useful to them.. It is
> my belief that this part of gnome/nautilus is under-utilized while it can
> boost more script creation, more script usage and overall give a higher
> esteem to Nautilus itself as "even more useful". (hope you get what I mean,
> my english suck, I know :)
> 
> I would like to ask the Nautilus team to add at least 2 scripts by default
> for Gnome 2.4. Speaking about me personally, I would say that the one script
> that I can't live with is the "Open Terminal Here" which opens a terminal to
> the currently opened nautilus directory....
> 
> Other cool stuff to consider: automatic tar.gzip of the file/dir(s) selected
> in the file manager or in the desktop, a graphical Grep (programmers will
> like this), a File Type MIME utility/editor for the file selected, the Run
> utility (I believe its place is in there, not in the root menu - same goes
> for "Open Terminal", shouldn't be in the root dektop menu -- too geeky :),
> and of course the 'Change Background Image' addon (also should not be in the
> root menu, it is not something that it should create clutter there, as
> people don't change their bg images all day. Let's just not be KDE please in
> this matter. ;-)).
> 
> Other addon ideas include "Send to Email", Send to Fax, Send to bla-blah,
> ToUpper (uppercase the filenames), ToLower, Dos2Unix (changing the carriage
> return of a text file), Unix2Dos, Mac2Unix and of course "Touch" (which
> calls the "touch" unix command :) and the list go on... I am not saying that
> all of them should be there by default but a good selection should be to
> enhance Nautilus and utilize stuff easier.
> 
> I understand that currently Nautilus Scripts are primarily bash scripts
> IIRC, but I believe a real add-on framework should be in place (not sure if
> Nautilus have that but I have seen 0 graphical addons/scripts so far). The
> addon framework doesn't have to be complex, in fact, it is pretty easy to
> implement. Steal some ideas from here (the protocol described below was
> coded by the same person who worked both on Nautilus and who previously
> wrote all by himself the BeOS Tracker (today he works on Apple's Finder ;)):
> http://bang.dhs.org/be/bebook/Tracker/Tracker%20Add-ons.html#Tracker%20Add-on%20Protocol
> 
> Additionally, I would advocate that I don't like much applications adding
> their own context menu entries in the root Nautilus menu as File-Roller did
> recently. I mean, I hate my Windows and KDE menus when they have a whole
> bunch of options added there by third party apps without asking me first...
> And it is bad enough that there is no way I can take them out easily or
> without having the knowledge of how to go about it. Please note that I am
> *not* against menu option additions. I just believe they should go under the
> "addon" submenu on Nautilus (previously "Scripts" in my mind) and play nice
> with the addon framework. I like clean stuff. ;-)
> 
> Best Regards,
> Eugenia