Re: [Nautilus-list] script w/ mime handling

[Vlad Harchev <hvv hippo ru>]

On Thu, 18 Oct 2001, John Sullivan wrote:

 Hi,

 Guys, please look how Midnight commander (a norton commander file manager
clone) scripts are defined. MC has a user menu (activated by pressing F2) that
will show items that are allowed for the file under the cursor on the active
panel. It allows to specify conditions under which the menu item is shown.
 Here are relevant pieces of 'man mc':

       The  format  of  the  menu file is very simple. Lines that
       start with  anything  but  space  or  tab  are  considered
       entries for the menu (in order to be able to use it like a
       hot key, the first character should be a letter). All  the
       lines  that  start  with a space or a tab are the commands
       that will be executed when the entry is selected.

       When an option is selected all the command  lines  of  the
       option  are  copied  to  a temporary file in the temporary
       directory (usually /usr/tmp) and then that  file  is  exe-
       cuted. This allows the user to put normal shell constructs
       in the menus. Also simple macro substitution  takes  place
       before  executing the menu code. For more information, see
       macro substitution.

[..]
       Default Conditions

       Each menu entry may be preceded by a condition. The condi-
       tion  must  start from the first column with a '=' charac-
       ter. If the condition is true, the menu entry will be  the
       default entry.

       Condition syntax:   = <sub-cond>
         or:               = <sub-cond> | <sub-cond> ...
         or:               = <sub-cond> & <sub-cond> ...

       Sub-condition is one of following:

         f <pattern>       current file matching pattern?
         F <pattern>       other file matching pattern?
         d <pattern>       current directory matching pattern?
         D <pattern>       other directory matching pattern?
         t <type>          current file of type?
         T <type>          other file of type?
         ! <sub-cond>      negate the result of sub-condition

       Pattern is a normal shell pattern or a regular expression,
       according to the shell patterns option. You  can  override
       the  global  value of the shell patterns option by writing
       "shell_patterns=x" on the first  line  of  the  menu  file
       (where "x" is either 0 or 1).
       Type is one or more of the following characters:

         n  not directory
         r  regular file
         d  directory
         l  link
         c  char special
         b  block special
         f  fifo
         s  socket
         x  executable
         t  tagged

       For example 'rlf' means either regular file, link or fifo.
       The 't' type is a little special because it  acts  on  the
       panel instead of the file. The condition '=t t' is true if
       there are tagged files in the current panel and  false  if
       not.

       If  the  condition starts with '=?' instead of '=' a debug
       trace will be shown whenever the value of the condition is
       calculated.

       The  conditions  are  calculated  from left to right. This
       means
            = f *.tar.gz | f *.tgz & t n
       is calculated as
            ( (f *.tar.gz) | (f *.tgz) ) & (t n)

       Here is a sample of the use of conditions:

       = f *.tar.gz | f *.tgz & t n
       L    List the contents of a compressed tar-archive
            gzip -cd %f | tar xvf -

---------------------------
 The last example above defines menu entry that is shown only for .tgz and
.tar.gz files and dumps the list of files in the archive.
 Another sample:

= f \.c$ & t r
+ f \.c$ & t r & ! t t
5       Compile and link current .c file
        make `basename %f .c` 2>/dev/null || cc -O -o `basename %f .c` %f

This uses regular expressions instead of shell patterns to match file names.

 The '%f' you see in the last line is a macro. Here are the macros MC
supports in menu entries:
----------------------------
       %f    The current file name.
       %d    The current directory name.
       %F    The current file in the unselected panel.
       %D    The directory name of the unselected panel.
       %t    The currently tagged files.
       %T    The tagged files in the unselected panel.
       %u and %U
              Similar  to  the  %t and %T macros, but in addition
              the files are untagged. You can use this macro only
              once  per  menu file entry or extension file entry,
              because next time there will be no tagged files.

       %s and %S

              The selected files: The tagged files if  there  are
              any. Otherwise the current file.

       %q

              Dropped  files.  In  all  places except in the Drop
              action of the mc.ext file, this will become a  null
              string, in the Drop action it will be replaced with
              a space separated list of files that  were  dropped
              on the file.

       %cd

              This  is a special macro that is used to change the
              current directory to  the  directory  specified  in
              front  of  it.  This is used primarily as an inter-
              face to the Virtual File System.
              This  macro  can  be used alone, or with arguments.
              If you pass  any  arguments  to  this  macro,  they
              should be enclosed in brackets.

              The  arguments  are: ascii to force the viewer into
              ascii mode; hex to force the viewer into hex  mode;
              nroff  to  tell the viewer that it should interpret
              the bold and underline sequences of  nroff;  unfor-
              mated  to  tell  the  viewer to not interpret nroff
              commands for making the text bold or underlined.

       %%

              The % character

       %{some text}

              Prompt for the substitution. An input box is  shown
              and the text inside the braces is used as a prompt.
              The macro is substituted by the text typed  by  the
              user. The user can press ESC or F10 to cancel. This
              macro doesn't work on the command line yet.

----------------------------
 The last  macro is extremely powerfull - it allows to ask user for
something!
 I think we should just adopt MC code for menu entries for Nautilus - it will
become extremely powerfull with them.
 What we should do IMO is to add a new subcondition 'm' that has a regex of
the mime type  as an argument.

 The only improvements I suggest is composing a file defining a menu by
reading all files in some directory instead of reading menu definition from
single file, and adding ability to translate menu item names and prompt names
(the ones %{some text} macro creates) to other languages (as a hack we can
just take a string and call _() on it in hopes that it's translated in some of
the .po files).

 This will bring Nautilus scripts to just several levels higher in
configurability and extensibility!
 That approach is also much better than mime-folder-hierarchy since it will
allow to define scripts that work with all images (i.e. files of type
image/<something> with just few lines)

= t n & m image/.*
c Convert file to JPG with quality 75
	convert -quality 75 %f `echo %f | sed -e 's/\.[^.]*$//'`.jpg
  
 rather than creating a mime/png mime/jpg mime/bmp etc directories in the
mime-folder-hierarchy.

 -Vlad

> on 10/18/01 2:53 PM, Tuomas Kuosmanen at tigert ximian com wrote:
> 
> > On Wed, 2001-10-17 at 18:17, John Sullivan wrote:
> > I think technically the mime-folder-hierarchy wouldn't be too hard, but I
> > think there are at least four major usability problems with it:
> > 
> > (1) It puts the burden on every user (or the installer program if there is
> > one) to put each script in the right place. This is much more error-prone
> > than if the script just "does the right thing" in the Scripts folder.
> > 
> > No, if you dont know about the mime hierarchy, just dont create one. If
> > the user has a ~/.gnome/nautilus-scripts/mime/ directory, then nautilus
> > would treat scripts inside the mime/ folder so that they only show up in
> > the menu if the mime type matches the path name under mime/ (image/jpeg
> > for example). All "normal" scripts would still be in
> > ~/.gnome/nautilus-scripts/ like they are now.
> > 
> > (2) Using the hierarchy in this way precludes a commonly-asked-for feature
> > of letting the user create arbitrary subfolders in the scripts folder.
> > 
> > You still can, you just dont want to name your subfolder "mime".
> 
> You wouldn't be able to mix the two. Either a script would be in the mime
> hierarchy, and not organized arbitrarily, or vice-versa. Two parallel
> hierarchies with the same root for completely different purposes sounds
> confusing at least. I suppose in practice you could use links to ensure that
> there's only one actual copy of each script, but it still seems confusing.
> 
> > (4) If the Scripts menu reflects the folder hierarchy, then you've got to
> > navigate multiple levels of hierarchical menus to choose a script, which is
> > a pain. If the Scripts menu doesn't reflect the folder hierarchy, then
> > there's a hard-to-understand relationship between the Scripts folder and the
> > Scripts menu.
> > 
> > No, the MIME scripts could even be on the context menu's toplevel, there
> > could be a new group between "Rename" and "Move to Trash" where those
> > would be. Like Jonathan's "Format floppy" example. Since the scripts you
> > put to the mime stuff are likely to be pretty specific, and you would
> > not be having all your scripts on the menu at once like you do now with
> > the "all scripts handle all files" situation.
> 
> I understand your proposal, but I still think it is a confusing
> relationship: Scripts at the top level (or in user-created arbitrary
> folders) show up in the Scripts menu. Scripts inside the "mime" subfolder at
> various levels (mime/image/*, mime/image/jpeg/*) are flattened and inserted
> into the File and right-click context menus as if they were standard
> built-in menu items.
> 
> It sounds powerful, and confusing. I am always tempted to push back to
> minimize confusion, but I understand the allure of "powerful".
> 
> John