[comp.sys.atari.st] Desktop.inf + LESS

jbww@ukc.UUCP (01/27/87)

     There is more that can be done to modify the behaviour of
 the ST desktop than appears to be generally  realised, so hope
that the following notes are of use.  Any  information from those 
that can shed further light would be nice.


     As Bill Silvert recently pointed out, desktop.inf contains 
(mainly) plain ascii text, and the names of installed applications
can be edited to include path information :

> For example, suppose that you use EZSQUEEZ.PRG to unsqueeze files
> from a RAMdisk.  You click on it, then go to Install Application, and
> give the file extension ?Q?.  Then you save the desktop and edit
> DESKTOP.INF by inserting the path C:\BIN\ before EZSQUEEZ.PRG.  Next
> time you boot from that disk, any time you click on a squeezed file
> it will be automatically unsqueezed, so long as the file
> C:\BIN\EZSQUEEZ.PRG is available.


     There are other useful modifications that can be made,
     to configure the behaviour of the desktop.

     Recently, Peter Jaspers-Fayer queried whether it was possible to
do anything about the action of the desktop, when displaying/printing
a file.  This is particularly relevant now that LESS is available.

The few lines of desktop.inf before and including some application
installation information are :

#F FF 04   @ *.*@
#D FF 01   @ *.*@ 
#G 03 FF   *.APP@ @ 
#G 03 FF   *.PRG@ @ 
#F 03 04   *.TOS@ @ 
#P 03 04   *.TTP@ @ 
#P 03 04   d:\FASTBAS.PRG@ *.BSC@

The action of the desktop is clearly to try matching a 'double-clicked'
file against these templates, IN REVERSE ORDER.
Once a match has been made, the desktop then takes either the specified
action, or if none, the default action.

[ Thus if the bottom template is changed to d:\DUMP.TTP@ *.*@ then an
attempt will be made to dump ALL files. Interestingly, not only will 
.prg (etc) files not be executed, they will also not be displayed as
executables on the desktop. ]

If no other match is found, the top line wakes up the SHOW|PRINT|CANCEL
alert box that so incenses pjf (and me).
The simple solution is just to insert the name of one's favourite
display routine, as below.  This will then ensure that any 
non-executable is then read using the facilities of LESS, (thus ending
that sinking feeling, as the crucial paragraph that one was looking for
flashes off the top of the page.)

#F FF 04   d:\LESS.TTP@ *.*@ 
#D FF 01   @ *.*@ 
#G 03 FF   *.APP@ @ 
#G 03 FF   *.PRG@ @ 
#F 03 04   *.TOS@ @ 
#P 03 04   *.TTP@ @ 

     Printing is best handled by a proper configurable printer spooler,
     - a few examples exist,  but how about one that just looks and acts
       like a ram disk ? - (double click on icon to open,  multiple file
       copy/delete), as well as having printer info. for each file.
 
jbww@ukc.ac.uk    -  Physics Lab., University of Kent, Canterbury, U.K.


P.S.   have just come across some info. on the desktop that came by a
       while ago, from Michael Vederman. Hope someone finds it helps :

> From mcvax!seismo!lll-crg!lll-lcc!vecpyr!amd!pesnta!hplabs!ucbvax!UHUPVM1.BITNET!ACS19 Fri May 23 13:26:25 BST 1986
> 
> In response to someones query about the desktop.inf.... tah dah -----
> Everything you always wanted to know about desktop.inf, but were afraid to
> ask.  Below is a typical desktop.inf file (with  a few changes added for
> examples).  Below each line is a definition of what each value represents.
> 
> #a000100
> This is the first desk accessory, the rs232 config.  Each 0 represents the
> first column of buttons on the set rs232 config dialog box.  The first
> 0 is column 1 row 1, the second 0 is coumn 1 row 2, etc.  A 1 value
> indicates that a button in the second column was chosen.
> 
> #b000000
> This is the set printer config.  It works the same way as the rs232 config.
> 
> #c7770007000600070055200505552220770557075055507703111103
> This is the color palette.  The color value is set using 3 digits at a time,
> representing the red, green and blue values.  The 3111103 at the end deals
> with the keyboard repeat rate, and sensitivity.  (None of the above three
> will do anything if the associated desk accessory is not loaded)
> 
> #d
> This is apparently reserved for a fourth accessory, and does nothing at
> this time (so far as I can see).
> 
> #E C4 02   (#E=Extras)
> This is two things.  The first value has to do with both the Set Preference
> dialog and the mouse double click rate.  The byte is broken down as follows
> with the indicated bit set performing the noted action:
> 
> Bit       7       6       5       4       3    |   2       1        0
> Value    128     64      32      16       8    |   4       2        1
>      displays  sorted  sorted  confirm confirm |   double click rate
>        TEXT      by      by    deletes copies  |   all three bits, values
>    (if not set  size    date                   |   may only be from 0-4
>      displays    \       /                     |   5-7 will turn off the
>       icons)     both bits                     |   mouse buttons
>                   sort by
>                    type
> 
> If neither bit 5 or 6 is set the sort is by name
> 
> The second value is 03 for hi rez, 02 for medium rez, or 01 for low rez.
> 
> #W 00 00 02 0B 2A 0B 08 A:\*.*@        (#W=Window)
> #W 00 01 0A 01 45 09 08 A:\TEST.C\*.*@
> #W 00 00 0E 09 2A 0B 08 A:\*.INF@
> #W 00 00 0F 0A 2A 0B 00 @
> The above four are the window defs.  The first number is how far over the
> horizontal slider is, the second is the vertical slider.  The third number
> is the x coordinate of the left hand side of the window (this takes on even
> values, with odd values the same as next lowest even value).  The fourth
> number is the y coordinate (this takes single increments).  The fifth and
> sixth numbers are the width and height, respectively.  The last number
> indicates where on the screen the window will open from. (The window opens
> with a different shape and from a different place with each number, but when
> you close the window, it will go to another place on the screen.  I have not
> hacked at this long enuf to figure it out.)  A zero or FF will not open the
> window.  The text indicates which drive's contents will be displayed.  If
> the drive does not exist, the window won't open, ie. drive bits not set.
> Also, if the display validation is omitted, the window won't open.
> The second def above will display the contents of the folder TEST.C, while
> The third def above will open a window, and only display the .INF files
> on drive A.  If you close and open the window, the files will display as
> defined in the file and program defs below.  (NOTE: this only applies to
> icon images, every file will display in text  -- except if the file bits
> are marked to be hidden, system, volume, read/write and whatever other
> bits there are, in which case it won't display at all, but if it is read
> only, it will display -- strange HUH?)  The bottom-most open window in
> the list will be the active window.
> 
> #M 00 02 00 FF D FLOPPY DISK@ @      (#M=iMage (?))
> #M 00 00 00 FF A DRIVE A@ @
> #M 00 01 00 FF B FLOPPY DISK@ @
> These describe the icon attributes.  The first two numbers are the column
> and row position of the icon.  The column can be from 0-7, the row 0-3.
> The third number determines the icon image which will be displayed.  The
> image number is the same for this and the remaining defs in desktop.inf, as
> follows:
> 
> 0= disk drive (drawer)       1= folder (sub-directory)      2= trash can
> 3= executable file (.PRG, .TOS, or .TTP)   4= text (stack of papers)
> 
> The fourth value doesn't seem to do anything, but must be a place holder for
> an unimplemented function.  The single letter is the drive identifier, and
> the text is the drive name.  The first @ indicates the end of the drive name.
> The second @ does nothing, but we can speculate as described below for the
> file identifiers.  The order in the list determines the visual heirarchy
> of the icons, ie. which will display on top when moved over another icon.
> 
> #T 00 03 02 FF   BLACK HOLE@ @    (#T=Trash)
> This is the same as the disk drive.  If you move a disk drive identifier
> below this in the list, it will display on top of the trash if moved to the
> same location.  The trash has no identifier letter, but you can put one in.
> 
> #F 03 04   @ *.INF@      (#F=Files)
> #D FF 01   @ *.C@        (#D=Directories)
> These two determine which type of file or directory will be displayed, when
> displayed as icons.  The first line will make GEM display only .INF files
> for use with the SHOW, PRINT, CANCEL alert box.  If you delete this line,
> no icons will be shown for any file, except as defined below for programs.
> The second line does the same for sub-directories, only .C folder icons will
> show.  When files are displayed as text, all files will be there, but if
> you single click on an 'undefined' file type, the sytem will reboot.  If you
> double click, the name will be highlighted, but you can't do anything.
> 
> #G 03 FF   *.APP@ @      (#G=Gem)
> #G 03 FF   *.PRG@ @
> #F 02 04   *.TOS@ @      (#F=File)
> #P 03 04   *.TTP@ @      (#P=Parameters)
> The above four determine the types of files defined as executable images.
> Notice that the #F, #D, #G and #P all have two @ symbols.  This is defined
> as:  the text before the first @ tells GEM this is a def for an executable
> file, while text after the first @ and before the second @ tells GEM that
> this is a def for a SHOWable file (ASCII or object).  Note that if both are
> specified, like    #G 03 04   1ST_WORD.PRG@ *.TXT@    then when you double
> click on any .TXT file, the 1ST_WORD.PRG file will run, and the .TXT file
> will be taken as a parameter.
> The first number indicates the icon image for the file before the first @,
> and the second number indicates the icon image for the file between the @'s.
> 
> Note that the disk drive def also has two @, which would indicate that the
> FF is a def for the text in between the @'s, but I couldn't get anything
> to happen.
> Try playing around with your desktop.inf by placing different values for the
> icon images (can be kinda fun).  Be forewarned, tho, you can thoroughly
> confuse GEM, although no harm will result.
> 
> This concludes the desktop.inf tutorial (for disk based desktop.inf, there
> are a couple of desktop.inf's in memory which can do things, too).
> There may be more to it, but I haven't figured it out yet.
> 
> >From Houston,
> Michael Vederman
> ACS19@UHUPVM1

	Regarding the last point :
one is a direct ascii copy of the desktop, as it would be saved to disk,
the other is the actual 'working copy'. Temporary changes to the way the
desktop acts (that are not to be recorded to disk) need only modify the 
latter copy ( i think )

		any further info. ?      - jbww