Conference bulova::decw_jan-89_to_nov-90

    
    I beleive there is a program called PAUSE which does the same
    thing as BACK, except to the pause screen...
    
    (I love the RHINE.XBM background!)
    
    Dave
    

    Pointer please.

     Are you trying to modify a BACK.C program to use the "Pause"
     window instead?  If so, I'm sure that Paul S. Winalski's
     Xfish (see the old conference, note 1282.38 or later) has
     code to find both the window manager root window and the
     "Pause" window.  Do whatever BACK does now, but do it
     instead to the "Pause" window.
     
     Dan

    I don't have the sources at all, but like the idea and want someone who
    knows this stuff to either step forward here or in mail.
    
    thanks
    
    andy

PSW::PSW$DUA1:[WINALSKI.FISH]FISH.C contains code to find the screen background
window and the session manager's pause window.  Once you have the window IDs,
you can do whatever you want to them, including setting the background color
or pixmap.

--PSW

    
    Here's one I got from someone on the net -- sorry, I don't remember
    who.   It doesn't have a real name that I know about, so I call
    it "XSETPAUSE".  By the way, there's no command interface: you have
    to point a logical name at the bitmap file you want to display.
    

    
/*
 * simple X windows program to set the pause screen
 */

/*
 * include files
 */
#include <stdio.h>
#include <math.h>
#include <string.h>
#include <signal.h>
#ifdef VMS
# include <decw$include/Xlib.h>
# include <decw$include/Xutil.h>
# include <decw$include/cursorfont.h>
# include <decw$include/Xresource.h>
# include <decw$include/DECwmHints.h>
# include <sys$library/time.h>
# include <sys$library/types.h>
# include <sys$library/timeb.h>
#include <ssdef.h>
#include <lnmdef.h>		/* logical name definitions		*/
#include <descrip.h>
#else
# include <X11/Xlib.h>
# include <X11/Xutil.h>
# include <X11/cursorfont.h>
# include <X11/Xresource.h>
# include <X11/DECWmHints.h>
# include <sys/time.h>
# include <sys/types.h>
# include <sys/timeb.h>
#endif


/*
 * objects
 */
Display   *disp;
Window    theWindow;
Window    rWindow;
Window    sWindow;
Window    oWindow;
Pixmap    stipP;

/*
 * global variables
 */
int	screen;
int	x, y;

/*
 * bitmap file to load in (change it to your preferred)
 */

#ifdef VMS
char *bitfile;
typedef struct				/* this structure is used	*/
  {                               	/* during calls to SYS$TRNLNM	*/
  short		buff_len;
  short		code;
  char	      * buff_pntr;
  short	      * ret_lenp;
  } trnlnm_item;

char LANG$LOG_NAME_TABLE[] = "LNM$PROCESS_TABLE";

#else
char bitfile[] = "gaston.xbm";
#endif

/*
 * SetBackgroundToBitmap: Set the pause window background to a caller supplied 
 *                        bitmap.
 * taken and modified from xsetroot
 *
 */
SetBackgroundToBitmap(bitmap, width, height)
    Pixmap bitmap;
    unsigned int width, height;
{
    Pixmap pix;
    GC gc;
    XGCValues gc_init;
    int fore_color, back_color;

    gc_init.foreground = BlackPixel(disp
				   , screen
				   );
    gc_init.background = WhitePixel(disp
				   , screen
				   );
    gc = XCreateGC(disp
		  , sWindow
		  , GCForeground|GCBackground
		  , &gc_init
		  );
    pix = XCreatePixmap(disp
		       , sWindow
		       , width
		       , height
		       , (unsigned int)DefaultDepth(disp, screen)
		       );
    XCopyPlane(disp
	      , bitmap
	      , pix
	      , gc
	      , 0
	      , 0
	      , width
	      , height
	      , 0
	      , 0
	      , (unsigned long)1
	      );
    XSetWindowBackgroundPixmap(disp
			      , sWindow
			      , pix
			      );
    XFreeGC(disp
	   , gc
	   );
    XFreePixmap(disp
	       , bitmap
	       );
    XClearWindow(disp
		, sWindow
		);
}

/*
 * routine to read the bitmap file into a pixmap (taken from xsetroot)
 */
Pixmap ReadBitmapFile(filename, width, height, x_hot, y_hot)
    char *filename;
    unsigned int *width, *height;
    int *x_hot, *y_hot;
{
    Pixmap bitmap;
    int status;

    status = XReadBitmapFile(disp
			    , sWindow
			    , filename
			    , width
			    , height
			    , &bitmap
			    , x_hot
			    , y_hot
			    );

      return(bitmap);
}

/*
 * routine to find pause window (taken from PSW's fish program)
 */
Window SmPauseWindow(dpy, root)
    Display *dpy;
    Window root;
{
    Window r2;
    Window parent;
    Window *child;
    Window *child1;
    Window *child2;
    unsigned int nchildren, nc1;
    XWindowAttributes rootatt, childatt;
    int x, y, w, h, bw, d;
    
    if (!XGetWindowAttributes(dpy
			     , root
			     , &rootatt
			     ))
	return 0;

    if (XQueryTree(dpy
		  , root
		  , &r2
		  , &parent
		  , &child
		  , &nchildren
		  ))
        {
	int i;
	
	for (i = 0; i < nchildren; i++)
	    {
	    if (!XGetWindowAttributes(dpy
				     , child[i]
				     , &childatt
				     ))
		return 0;

	    if (childatt.width == rootatt.width - 6 &&
	        childatt.height == rootatt.height - 6 &&
	        childatt.x == 0 &&
	        childatt.y == 0)
		{
		if (!XQueryTree(dpy
			       , child[i]
			       , &r2
			       , &parent
			       , &child1
			       , &nc1
			       ))
		    return 0;

		if (nc1 == 1)
		    {
		    if (!XGetWindowAttributes(dpy
					     , child1[0]
					     , &childatt
					     ))
			return 0;

		    if (!XQueryTree(dpy
				   , child1[0]
				   , &r2
				   , &parent
				   , &child2
				   , &nc1
				   ))
			return 0;

		    if (childatt.width == rootatt.width - 6 &&
			childatt.height == rootatt.height - 6 &&
			childatt.x == 0 &&
			childatt.y == 0 &&
			nc1 == 2)
			return child1[0];
		    }
		}
	    }
        }

/*
 * If we get here, we can't find the proper window
 */
    
    return 0;
}


/********************************************/

/**************/

main(argc, argv)
    int   argc;
    char *argv[];
/**************/
{
    int i,dpcs,n,fcnt;
    char *strind;

    struct dsc$descriptor tabnam, lognam;
    int status, found, attr, depth, index;
    short  dummy, lnm_ret_len;
    struct
      {              
      trnlnm_item   item1;
      trnlnm_item   item2;
      int	    terminator;
      } itmlst;   
    char buff[100];
    char *bitfile;
    char *display = NULL;
    char xlat_name[] = "PAUSE$FILE";
    int  buff_len = 100;
    int  str_len;
    unsigned long   gc_mask;
    XVisualInfo	vinfo;
    Atom		dwm_atom;
    DECWmHintsRec	dwm_hint;
    unsigned int width, height;
    
    /*
     * Open up the display. 
     */
    if ((disp=XOpenDisplay(display)) == NULL) 
        {
        fprintf(stderr, "%s: Can't open display ''\n",argv[0],display);
        exit(1);
        }
    
/*
 * find root and pause windows
 */
    screen = DefaultScreen(disp);

    rWindow = DefaultRootWindow(disp);
    sWindow = SmPauseWindow( disp
			   , rWindow
			   );

/*
 * find the filename pointed to by PAUSE$FILE
 */
#ifdef VMS

    attr = LNM$M_CASE_BLIND;
    index = 0;

    tabnam.dsc$w_length = sizeof(LANG$LOG_NAME_TABLE) - 1;
    tabnam.dsc$b_dtype = DSC$K_DTYPE_T;
    tabnam.dsc$b_class = DSC$K_CLASS_S;
    tabnam.dsc$a_pointer = LANG$LOG_NAME_TABLE;

    lognam.dsc$w_length = sizeof(xlat_name) - 1;
    lognam.dsc$b_dtype = DSC$K_DTYPE_T;
    lognam.dsc$b_class = DSC$K_CLASS_S;
    lognam.dsc$a_pointer = xlat_name;

    itmlst.item1.buff_len = sizeof(int);
    itmlst.item1.code = LNM$_INDEX;
    itmlst.item1.buff_pntr = &index;
    itmlst.item1.ret_lenp = &dummy;

    itmlst.item2.buff_len = 100;
    itmlst.item2.code = LNM$_STRING;
    itmlst.item2.buff_pntr = buff;
    itmlst.item2.ret_lenp = &lnm_ret_len;

    lnm_ret_len = 0;

    itmlst.terminator = 0;
/*
 * get the size of the filename
 */
    status = sys$trnlnm(&attr,&tabnam,&lognam,0,&itmlst);
                            
    if ( status == SS$_NORMAL )
      {
/*
 * allocate a filename
 */
      bitfile = calloc(1, lnm_ret_len );
      itmlst.item2.buff_len = lnm_ret_len;
      itmlst.item2.code = LNM$_STRING;
      itmlst.item2.buff_pntr = bitfile;
      itmlst.item2.ret_lenp = &lnm_ret_len;

/*
 * fetch filename
 */
      status = sys$trnlnm(&attr,&tabnam,&lognam,0,&itmlst);
      }
    else
      {
      exit(0);
      }
#endif

/*
 * read the bitmap file into a pixmap
 */
    stipP = ReadBitmapFile( bitfile
			  , &width
			  , &height
			  , (int *)NULL
			  , (int *)NULL
			  );
/*
 * apply the pixmap to the pause window
 */
    SetBackgroundToBitmap( stipP
			 , width
			 , height 
			 );
/*
 * and sync things to take the update
 */
    XSync( disp
	 , False
	 );

}
    
    

    I have received this from several sources, including .EXE, but have
    been unable to make it work under X5.2-40A.
    
    I've issued a DEFINE/SYS/EXEC/USER PAUSE$FILE disk:[dir]file.XBM and
    then RUN XSETPAUSE, but no joy.
    
    Andy

     OK, got it. No disk or [dir]. It works now.
    
    thanks.
    
    andy

    After a large amount of mail and having made the mistake of pointing
    people at my workstation, I've placed 100-odd .XBM files and the .EXE's
    necessary to display them, built for VMS V5.1 SDC and X5.2 IFT, in
    UKCSSE""::SYS$PUBLIC:.
    
    Have fun. If you have additional files, please mail me pointers.
    
    Thanks, 
    
    Andy

    Make that 350-odd .XBM files, plus an XBM.EXE that displays files in
    their own window.
    
    Have fun.
    
    Andy
    
    PS be warned, UKCSSE""::SYS$PUBLIC: contains just under 100,000 blocks
    of files!

Andy,

Do you have sources for XBM.EXE?

Dick

    Yup, in the same directory. At least one other person is hacking it
    too.
    
    The author asked me to point out that it was his first x program, so be
    kind!
    
    Please let me have the improved versions so that I can make them
    available from the same place.
    
    Andy

    Anyhow, has anyone hacked XSETROOT (aka BACK) and XSETPAUSE so that
    they don't need to be run from a window?

For those who wan't one utility that does it all ABEL::VUE$LIBRARY:XSETROOT.EXE.
This one will let you setup a bitmap for the background with the normal -bitmap
option and the pause window with the -pbitmap.


Sean

    applause!
    
    A

       
       
       	Can you make the source available??
       
       						mike

re: .16

	I don't know much about X but it works and you can find this in
	SEAN::USER:[DAVIDSON._PRG.C]XSETROOT.C.  This is another variation
	on PSW's routine in fish.


Sean

	Thanks Sean!

							mike

        So is anyone working on an xbm or xsetroot that understands ddif
        rather than xbm files. These store about 1/4th of the space
        required by .xbms. which would free up about 75k blocks for you
        andy....
        
        q
        

What is the major resources consumed by BACK/XSETROOT when displaying
a large file?   Some of the large .XBM causes the process running BACK/XSETROOT
to die with an insufficient resource error after it sucks up all CPU cycles
for a few minutes.  SHOW PROCESS doesn't reveal anything obvious.
I'm new to DECwindows.

-Mike

XBM to Ps  converter JUNO""::XBM_PS.EXE

To invoke it correctly do either

MC []XBM_PS  <xbm file name>  /Switchs 

or

THING:==$disk:[directory]XBM_PS   then           THING  <xbm file name> /Switc

Switchs are 

/A3     specifys that the picture should be 'fitted' to an A3 page     
        (subject to still retaining the picture height/width ratio)
         the default is an A4 page

/FILL   specif=ys that the picture should be enlarged to fit the page     
        (ie you can enlarge a small XBM file to fill (nearly)
        all the output page  (if you 'enlarge' too much you start to
        see individual pixels)


/QUEUE=queue  submit the created .ps file to this queue (with the correct
	      parameters for an LPS40)

/DELETE       delete the .PS file after printing


The output .Ps file is    <input file>.PS

>What is the major resources consumed by BACK/XSETROOT when displaying


Well one of the things that seem to make XSetRoot take a long _time_
is the use of Read_Bitmap_File to read the .XBM file

On our 6320, reading DayBreak_Cut with Read_Bitmap_File takes
(about) 45 seconds, but using 'normal' Rms $Get's this only
takes (about) 14 seconds

r xbm_read     (rms reads)
---------.XBM file read complete ----------
 ELAPSED:    0 00:00:14.18  CPU: 0:00:14.91  BUFIO: 6  DIRIO: 71   FAULTS: 1959

r im           (Read_Bitmap_File)
---------.XBM file read complete ----------
 ELAPSED:    0 00:00:57.43  CPU: 0:00:21.70  BUFIO: 20 DIRIO: 1109 FAULTS: 347

----------------------------------------------------------------^


(The only reason that I'am not using  Read_Bitmap_File is that
I was reading .XBM's without DECwindows (before I moved to DW)
and thought I'd try and see what took the time up in XsetRoot)

For unknown reasons I've put together _my_ version of
XSetRoot, most of the code/ideas have been cribbed
from other programs in Examples. I don't think there is
anything really new here, only in a different order

With my SetRoot you can....

Draw a .XBM (X11) file to either the pause screen
or the root screen, you can draw the image with
any of the 'named' colours as foreground or 
background. The draw can be either done as
XSetRoot does and duplicate a single
image many times to fill the screen or just
draw _one_ copy of the picture to the screen.
If you request just _one_ image then you
can also request where it should be placed on the screen

A text string (a message) can also be drawn as above,
ie you can name the foreground/background colours, request
multiple copies etc etc etc, you can also specify the
font size to be either 8,10,12,14,18,20 or 24

EG

draw the X11 image waterfall.xbm to the root window (the default)
with a RED foreground, a black background, only one
copy of the picture should be drawn , located at x=300,Y=70

MC []ROOT IMAGE /FILE=WATERFALL.XBM/FORE=RED/BACK=BLACK/SINGLE/LOCATE=(X=300,Y=70)

Display the message "I'am not here" on the Pause window,
with white foreground and green background in text 24 points
high

MC []ROOT   MESSAGE/MESSAGE="I'am not here"/FORE=WHITE/BACK=GREEN/SIZE=24/PAUSE

This will give you a screen image like...


I'am not here I'am not here I'am not here I'am no
I'am not here I'am not here I'am not here I'am no
I'am not here I'am not here I'am not here I'am no
I'am not here I'am not here I'am not here I'am no


The program is JUNO""::ROOT.EXE, if there are no
changes in the next few days I'll post a pointer
to the source modules in Examples  (there is .CLD and two source modules)





This program stiil uses the 'slow' method of reading the X11 image
(X$Read_Bitmap_File) cos though I can create a bitmap in
my program how can I pass this to (say) X$Copy_Planes ???

    Pete
    	PLEASE work out the fast way to load the bitmap! My poor old VS2000
    cpu thanks you, I thank you, etc etc 
    
    goot work
    
    andy

>    	PLEASE work out the fast way to load the bitmap! My poor old VS2000

Well I dont know if I can, at the moment I call  Read_bitmap_from_file
this returns me a bitmap ID that I can pass to Copy_Planes. Now I can
create a bitmap a lot faster that Read_bitmap... but then how do
I pass this to copy planes????

Seems like a general problem to me, I can create structures
(bitmap,pixmap etc) only from X calls, and only work on them via
X calls... whats so wrong with giving me the address of this structures
rather than an ID, so then I can work on them directly

There are a couple of ways you can get bitmaps faster than XReadBitmapFile.
You can #include a bitmap file or explicitly include its contents in your
C source and then call XCreateBitmapFromData.  This is the simplest
approach but limits the variety of bitmaps available.

You could also save the bitmaps in some other format (ie: .DDIF) and then
use some faster mechanism for reading them.  In the end you still create
pixmaps.

IDs in X usually are the addresses of the small part of the structure
which resides on the client.  The problem with things like pixmaps is that
most of the information that you would want to modify in them resides on the
server.  Because of that you can't do direct manipulation even if you want
to.  What it comes down to is that a Pixmap is not just a structure.

In any case most of the speed problems in Pixmap manipulation is in the
initial read from disk.  If you can speed that up or eliminate it you will
get the most for your effort.

Dick

Following on from the last few...


Is there a way to get a PixMap to 'live' beyond the current image..

What I'd like to do is create a pixmap from one process, save
its ID (as a property set on a window) then later use this pixmap
from another process  

Can this be done ???

You can set your display's close-down mode to be "RetainPermanent".  Then
none of your resources will disappear when your display goes away.  You
can get rid of the resources by issuing a KillClient on one of them.
I suggest that if you really need to do this, you should open a special
connection just for the pixmap so that you won't leave a lot of other
trash lying around.

Burns

There is a new version of _my_ setroot, JUNO""::ROOT.EXE
this uses my method to read the bitmap file (and then uses 
create_bitmap_from_data) to create the bitmap ID, this should reduce 
the time taken .... Ie the 'old' method (ie XSetRoot) took (about)
40 secs to read DayBreak_Cut, the 'new' method only takes (about) 10
secs

The new method of reading the XBM (X11) file is _very_ fixed format
ie it wont deal with any changes to what it thinks should be
the file format, it seems to read all of the XBM's
I have here  (if you get a problem please contact me)

re .-1

> I suggest that if you really need to do this, you should open a special
> connection just for the pixmap so that you won't,lear-7,������������

I've good news and bad news...

The Good news....

You asked for it (.19) and here it is, a version of SetRoot
that provides _limited_ support for DDIF files

JUNO""::ROOT.EXE

DDIF files are much smaller than .XBM files

DAYBREAK_CUT.DDIF       217/ 219       Blocks
DAYBREAK_CUT.XBM       1109/1110       Blocks


and can be loaded faster than XBM files

Example (Reading Daybreak_cut)

Reading a DDIF file                       2 Seconds
Using my method to read a .XBM           12 seconds
Using the old method of reading a .XBM   50 seconds



The decision to treat the input file as a DDIF or XBM file is based
on the input filename Extension, if the Extension is .DDIF the
file is read as a DDIF file, _anything_ else and its treated as 
a .XBM file


IE   MC []ROOT IMAGE/FILE=DAYBREAK_CUT.DDIF will treat the file as DDIF
     MC []ROOT IMAGE/FILE=DAYBREAK_CUT.something will treat the file as XBM


I've converted (via UTOX) all the .XBM's I can file to DDIF, these are
located at THEBIT""::THEBIT$DUA0:[UIS]*.DDIF


{ Ps I'am leaving this group soon (check the personal name) and will be
unable to maintain the contents of this disk after the 19Th of May,
this disk contains...  

*.XBM    the original XBM files
*.PS     the postscript conversions
*.DDIF   the DDIF versions
*.UIS    the UIS versions

Maybe someone would like to copy this lot ???  }


The above was the good news... now the bad news

(forgive me if I explain basic concepts here.. they wasn't to me
on Friday)  A .DDIF file can contain _anything_, text, graphics, colour
images B&W images etc etc etc, in short (IMO) a .DDIF file can be
looked on as just a 'container' for whatever you want. Now the only
sort of 'contents' that my setroot can deal with (at the moment) are
raw (uncompressed) bitmaps, if you try and feed root anything else
it will die with a "SORRY!!! unable to deal with..." message

and

some DDIF files I've found (output from a scanner) seem to have
a bitmap compressesd in something called G42D CCITT compression,
at the moment I cannot deal with this  (any ideas out there????)

(a note in ::IMAGING seemed to imply that I could use a callable
product called VSL (??) to uncompress these, but would this mean
that any site wanting to use ROOT would have to have VSL installed
also???????)

Any problems (or suggestions) please let me know (as long as its before
the 19Th of May)

> some DDIF files I've found (output from a scanner) seem to have
> a bitmap compressesd in something called G42D CCITT compression,
> at the moment I cannot deal with this  (any ideas out there????)

Just installed VIS, this allows you to expand a G42D CCITT compressed
file to an 'ordinary' DDIF file by the command

IMAGE AJUST filename.DDIF/NOcompress

    < Note 158.30 by BOOTIS::BAILEY "Clock Running, 25 Days Left" >

The decision to treat the input file as a DDIF or XBM file is based
on the input filename Extension, if the Extension is .DDIF the
file is read as a DDIF file, _anything_ else and its treated as 
a .XBM file

    The "correct" way to test for this is to check the RMS file semantics
    tag.  See the "V5.1 New Features" manual for how to do this.  Most
    DDIF files won't have the file type .DDIF - for example, DECwrite
    files are .DOC.

	Personally, I wouldn't mind installing VSL to have the added
	functionality..

	Thanks ever so much for ROOT! This is VERY nice!

							mike

    Where's the VSL kit?

       
       
       	Try VISUAL::IMAGING..
       
       							mike

Due to my upgrade to a GPX (from a 3500) having arrived unexpectedly
early ,node THEBIT no longer exists, if anyone wants any of the files
off THEBIT$DUA0:[UIS] please mail me and I'll set something up
to allow access to the new node outside of working hours (here in England)


(a 'C' vax GPX !!!!  Shame I'am moving soon.... I'll probably get
a mono Vs2000)

The lastest version of ROOT  (JUNO""::ROOT.EXE) contains the
code to expand compressed bitmaps 

This adds a little time to the display process but means you dont
have to exapand ddif files by using the IMAGE ADJUST command

As before... Any problems/suggestions etc please



Ps..  This version also contains a few bug fixes  (only the ones people
have told me about.. hint hint) ie the location of a message
displayed /SINGLE etc etc


pps.. there are two new ddif files JUNO""::*SHIP.DDIF that you may want,
these are the rather nice 'design' drawings of the Enterprise
and a kligon ship  (these came from UG to .PLO form, then to .UIS,
then to .DDIf)

Forgive me if a pointer has already been posted ( I haven't found it )
could we see the source code to root.exe?

- mike

I've tried to run the root.exe image on the DDIF files Juno""::*ship.ddif
and get an error unsupported document format (see below) the code
works greate on my .XBM files however. Have I overlooked something?


Totaly> ROOT :== "$SYS$USERSET2:[ROSSI.GRAPHICS]ROOT.EXE

Totaly> ROOT IMAGE /FILE=DECW$PICS:���nffff
ffffffff�� R"DISPLAY /CREATE /NODE=TOTALY::0��.Totaly> ROOT IMAGE /FILE=DECW$PICS:KRISTEN.XBM�*...
39 data bytes read from bitmap file�Height 720     Widt
576�Read of bitmap file complet
MELAPSED:    0 00:00:25.82  CPU: 0:00:19.63  BUFIO: 6  DIRIO: 39  FAULTS: 190 ��,Totaly> ROOT IMAGE

Re  Note 158.39

(Cannot send mail, node TOTALY not know here (or at Anchor)

Can you make your copy of SHIP.DDIF available some how to me
(copy it to JUNO""::XXX.DDIF is the best way) and I'll check it
out... both ship & spaceship work fine here.. either your
file is 'bad' in some way or for some other reason the cda routines
are having trouble reading your file (it'll be tomorrow before
I can check it out, its 22:13 here  (and Clint in Pale Rider is on!!)

I cannot think why the cda routines should be unable to read
your file, but I'll let you know

sorry, you should be able to reach me through asd::rossi, 
my DTN is 381-0210. I've coppied the file ship.ddif to juno""::xxx.ddif
I took this file from juno earlier using ftsv.

spool copy juno""::*ship.ddif *

I would also like the .ddif files you converted from .xbm and 
the source to root.exe?

-mike

        re .41
        
        I think you will find that FTSV (aka Spool) does not understand
        DDIF Semantics, which may be the cause of your problem. Try using
        set file/semantics=ddif *.ddif or copying the file using a vanilla
        copy command...
        
        q
        

>        I think you will find that FTSV (aka Spool) does not understand
>        DDIF Semantics, which may be the cause of your problem. Try using
>        set file/semantics=ddif *.ddif 

This fixed the problem for me....

Additional qualifier for Root  (JUNO""::ROOT.EXE)

(Image)    /SCALE=Floating_point_number


This allows you to enlarge or shrink an XBM/DDIF picture before
painting it on the pause or root screen

the X&Y axis values are multiplied by the given scale value,
IE    /Scale=0.5 will produce an image half the original size,
      /Scale=2.0 will produce an image twice the original size,
      /Scale=1.0 will do nothing... 1.0 times x = x

Scanned images lose detail if enlarged/shrunk outside the range
0.6 to 2.0, the generated art doesn't seem to suffer as badly
here   

IE KRISTEN.DDIF (generated) can be shrunk to /SCALE=0.2 and still be
(just) OK as a picture

but

THREE_WORLDS.DDIF (scanned) can only be shrunk to 0.5 and still
be OK as a picture  (the grow/shrink functions are done
by a call to IMG$SCALE)

As before, problems/suggestions to me (but I'am running out
of time now!!!)

    Re: .32
    
    >    The "correct" way to test for this is to check the RMS file semantics
    >    tag.  See the "V5.1 New Features" manual for how to do this. Most
    >    DDIF files won't have the file type .DDIF - for example, DECwrite
    >    files are .DOC.
    
    Ahem, this won't work for Ultrix...
    
    						-Dave

>    Ahem, this won't work for Ultrix...


Neither does my program tho....

New qualifier for the Image command  (thanks for the suggestion
Andy Leslie)


/FULL       This will automatically scale the picture to the maximum
            size possible (that will still fit on your screen)


note: this does not mean that the picture will completely
fill your screen, IE if you have a tall thin picture this will
be scaled up so the picture height will be the display height,
but the picture width will not fill the screen (only if the picture
aspect ratio is the same as the screen aspect ratio will the
picture completely fill the screen)

>>    Ahem, this won't work for Ultrix...


>Neither does my program tho....


Why not?

    The file(1) command on Ultrix was updated to return the correct result
    for DDIF, DTIF, and DOTS files.

    Does Root.exe convert DDIF formats to bitmap format for
    display to the cursor? If not, anyone know how this can be
    done?
    
    Thanks, J.P.

    Unless I misunderstand what you are asking, you can write out a bitmap
    from DECpaint in either DDIF or X11 format. The option is on the Save As...
    pulldown.

    To convert, read the DDIF file into Paint and write it out as X11...

-mike

    Yes, but you can't then apply this to the cursor...
    i.e. xset -cursor x.ddif...or x.xbm...
    
    xsetroot will not accept this going to the cursor..
    I believe it has to be converted to a different format and
    also a mask is needed. Any idea how to get that?
    
    Thanks,
    
    J.P.

New command for Root  (actualy its been there for some time, but
I forgot to document it...best tho to copy the new version cos
that does tab expansion  JUNO""::ROOT.EXE)

TEXTFILE

Writes a text file to either the Pause screen or  the root screen

Eg

MC ROOT TEXTFILE/FILE=LOGIN.COM/-
PAUSE/FORE=RED/BACK=BLUE/LOCATE=(X=200,Y=50)/SIZE=24

Will write the file login.com to the pause screen with red text
on a blue background (yuck) the text size will be 24 point, the
text will start at x=200,y=50

    I haven't seen this in the previous 50 odd replies, so...
    
    I would like to start root running from my decw$sylogin.com file
    and have it display to the pause window.  But root requires that
    the pause window have been displayed at least once before.
    
    Is there any way to do this from the decw$sylogin file (I bet not,
    but I'd love someone to prove me wrong...)
    
    Thank,
    
    Ken B.

I'd like the opposite functionality of /FULL.  Namely, I have a 1400 by
1400 (approx.) DDIF image that I'd like to have root scale *down* as
much as is required to fit on the screen.

You might say, "why not scale it with paint or UTOX", but paint can't deal
with an image that large and UTOX scales it in large increments.

Great tool! 

Thanks,

         == ken miller ==

>>>    -< And if you're taking requests... >-

Sure do !!!!

> I'd like the opposite functionality of /FULL.  Namely, I have a 1400 by
> 1400 (approx.) DDIF image that I'd like to have root scale *down* as


Ok you got it, new version juno""::root.exe

{Actualy there was very little change to make, all I had to do
was disable the "this image is too big " check _if_ this was
being done /FULL, cos the /FULL will just calculate the factor
to multiply the image by to get it to fit on the screen.... in your
case this factor will be less than 1.0... ie the image will  shrink)

        I think I should just write a batch procedure to copy these new
        versions of root.exe acroos every morning... :-)
        
        q

>        I think I should just write a batch procedure to copy these new
>        versions of root.exe acroos every morning... :-)


Well I think I'am running out of ideas now !!   But I'am certainly
running out of time.. the idea was for the new job to fill up
my time (but I'am starting to doubt this, _sigh_)

Will you post a pointer to root's source code and some of the .ddif
files you have before you leave?

> Will you post a pointer to root's source code and some of the .ddif
> files you have before you leave?



Well you can pick up the xbm/ddif files I have from  
LIBRAE""::LIBRAE$DUA0:[UIS]

*.DDIF   15570 blocks.
*.XBM    75114 blocks

(I dont't know what will happen to this directory after 19 May,
it'll probably hang around for a bit (but I'll take a copy to
a WORM at the new site)

Re  source

If I can I'll post a location before I go, failing that sometime
later (when I've tidyed up the code _a_lot_, the code looks very much
as if it was written as part of a learning curve, in my 'spare' time,
some of it via dial up)


BTW   My compliments to whoever but together the whole decwindows/ddif/toolkit
enviroment... its neat.. very neat, I started out with the Xlib
programming guide, then the CDA manual then the VIS manual and
am just starting on the toolkit manual, it all fits together rather
nicely  (I like the look of the toolkit a lot)


(Please dont take the above to imply that i'am any sort of programming
expert... just a small time hacker (not cracker))

neat... very neat

Besides the original code, a ROOT.DOC file would be convenient, to
describe all the features you've added.

Dan

        re .61
        
        try mc []root
        prompt> help
        
        Q. Who agrees that a .doc would be nice, but has found a way
        around it.)
        
        

Root seems to assume that the display device is 1024 * 864.  Is there a version
of Root that includes the idea that a Digital Workstation might be 1280 * 1024?

							-- Thanks, Phil

And todays version of Root....

New command VIEW   (qualifer /file=name)

This does not paint anything on your root or pause screen but
allows you to view a ddif or xbm bitmap picture, scale it
up or down, select fore and background colors, select single
and multiple images (using a scale and pushbuttons)

in short it allows you to play with an image

its crude (ok then _very_ crude) as this is my first stab
at using the toolkit (actualy thats why I put it together.. I
wanted an excuse to use the toolkit)

things I'd like to add (if (as usual) time permitting), file
input and output from a pull down menu, ability to have 
an alternate picture (seperate from the main), abilty to include
the alternate in the main, able to select colors from a named
pallete (as in Xcolors), able to 'cycle' through a directory
of files (nice for demo's)


this is still limited to a 1024 X 864 screen, but I'll fix that 
friday 

    The VIEW command is already used by the DDIF Viewer!

>    The VIEW command is already used by the DDIF Viewer!


no my View command is inside root...

ie   MC []ROOT  VIEW/FILE=FRED.XBM

When I try to MCR ROOT, I get a "exceeded quota" message.  Any idea
what quota that might be?

re Quota exceded... problem fixed off line (twas BYTLM)

However this has shown up another problem, within View...
after doing one scale a second one sometimes comes up with

...Performing SCALE...
OPCDEC opcode reserved to DIGITAL fault at PC=0080D17E, PSL=03C00000


Is anyone else seeing this problem  ??
Have I droped a cod somewhere??

>  Have I droped a cod somewhere??


Yes I had (in fact a few) .. fixed now (large Ddif images were being
truncated.. scanline errors on some Ddif)


While I'am here.... does anyone know how to...


(1) get the View Command window located at the bottom ??
    (Set_Values on the main Dialog box??)


(2) get the values in the pull down menu highlighted correctly

And now the last days are upon me..... 

Extension to the VIEW command...  CYCLE


Cycle allows you to view all (or just some) of the XBM or DDIF files 
in a given directory 

To use Cycle.... invoke the program  (you still must pass a file name
here), select single/multiple.. and the required forground and
background colors (the pictures are allways displayed times 1 scale)
... now call up the cycle menu

In the cycle menu you can select ...
view XBM or DDIF files
directory to search for these files
how to continue from picture to picture
(1)  on timeout (select vaue via a scale)
(2)  on button press
(3)  both of the above   (to get the next picture either wait for timeout
                          or press the button)

You can also select that you start the cycle with a given file...
ie if you have 300+ ddif files and you only want
to view files after xxx.ddif then enter XXX in the "start cycle"
field



Note:  using Cycle to view files over the network some times
causes root to abort  (times out the server I think)

JUNO""::ROOT.EXE

        <<< Note 158.70 by 43339::BAILEY "Clock Running, 4 Days Left" >>>

> Note:  using Cycle to view files over the network some times
> causes root to abort  (times out the server I think)

Wrong Wrong Wrong Wrong ......   what causes the abort is trying
to display the small  (16 X 16) files...  view cannot handle
these (why?).... I've just put up a new version that tests for
these small files and passes over them....


The reason I thought is was the network was cos all my
tests ran fine. (on local files). but when I tried it on 
remote files it died... the reason being that the remote directory
contains a few 16 X 16 files, and I did'nt notice till this
morning that it was allways the same files that view aborted on

....  anyway the new version seems to have fixed this

sorry !!!!!!

Sigh...  Since I added the View command (with all the nice toolkit things)
I've received Mail from a few people who have had problems invoking the program
(it looks like some people with low uaf/sysgen parameters cannot load
the new (bigger) program)

If you have problems loading/running the new flash up_to_date root
then try running the pre-view-command version of the program ...
all you will be missing is View


so now there are two programs!!!!

JUNO""::ROOT.EXE               provides the Image,Message,Textfile & View command
JUNO""::SIMPLE_ROOT.EXE        does not provide the image command 

Its all my own fault for trying to pack to many features into one
program...  really I suppose View should have been on its own 
this'll teach me to be OTT


(Actualy it'd be best to split off View anyway)

    Please specify the minma for the uaf/sysgen parameters involved.
    
    thanks
    
    andy

    How about that source?

New verison of ROOT   (yes I know that since I've moved jobs I (1) should'nt
be here and (2) should be too busy for this stuff..... but its a long story)

new qualifer for the IMAGE,MESSAGE and TEXTFILE commands

/WINDOW=hex window id (ie set the back ground of window n)

Eg   root image/file=nerd.ddif/window=00200045
will set the background of window 00200045 to the picture nerd.ddif

(note: the window id should be in HEX)

So now you can set the background of any window on your display

(this really is'nt that usefull since its mainly the root & pause
window you'll want to set... but its there and you may want to use
it)

one of the truely strange things you can now do is set the background
of a terminal emulator window... but its not quite what it sounds like
(I thought that if I set the background of a terminal window I would
get the text 'floating' on the background..but you also get a text
background.... try it.... its hard to explain  (and even harder on the eyes))


to get window id's there are many programs in the examples conf, including
FIND... which is used below    (also JUNO""::FIND.EXE)

FIND gives you a list of window id's... starting with your
current emualtor window and works its way _up_ the stack to the 
root window


$ RUN FIND
Id of Focus Window 0010001C  (1048604), Root id = 0008006B 

Window Id     X    Y Width*Height    Parent Id Type     Title
0010001C      0   20   667* 368 ( 2)  00100016    
00100016      0    0   667* 388 ( 2)  00100015    
00100015     -1   -1   667* 388 ( 1)  00200057  decw$terminal  Bootis_3
00200057      0   20   667* 388 ( 1)  00200055    
00200055    101  446   671* 412 ( 3)  00200012    
00200012      0    0  1024* 864 ( 8)  00200011    
00200011      0    0  1024* 864 ( 1)  0008006B    
 Outside envelope Window  X=101, Y=446   , (671 * 412)  
 Window ID = 00100015 (1048597)
DCL symbol WINDOW_ID set


and it seems like if you set the background of the first window
on the stack (0010001C) it 'sort of' sets the background
of the emualtor window (try it on a notes window so you
can do a Control W to repaint the screen).. the others dont
do very much (try it and see)    (but 0008006B is your root window)

any other ideas of what you can do with /WINDOW=nnnnn????

Note: I dont check the given window Id.. I just use it, so if you
get a bunch of rude messages from the server....its the wrong id



Ps... i promise promise promise promise promise promise to make
the source(s) available

The .DDIF & .XBM & .UIS files that were contained in LIBRAE""::LIBRAE$DUA0:{UIS]
have now gone  (they lost no time in deleting the directory after I left)

If anyone has a copy of the files please let me know

(but you can allways find some .XBM at     UKCSSE""::SYS$PUBLIC:.)


ps..  go on gissa.. go on.. I can do that

Did you take the source code with you? Will you make it available? I'd like to
get a version of ROOT running under Ultrix...

-Meyer

Is it possible to display a full colour (ie multi plane) picture
via the methods used by XSetRoot & Root  (Ie Set_Window_Background_Pixmap)
????????????????????

You pass a Pix map to Set_Window_Background_Pixmap so the
bottom line question is can you have a colour picture stored
in Pix format??
[EOB]






                                                            

    Can you post a pointer to the current location of ROOT*.EXE?
    (It's no longer on JUNO.)
    
    Also, does anyone have any of the .ddif files that were on LIBRAE?
    
    Thanks,
    
    -sjb

>    Can you post a pointer to the current location of ROOT*.EXE?
>    (It's no longer on JUNO.)


VANITY""::ROOT.EXE
    
>    Also, does anyone have any of the .ddif files that were on LIBRAE?
    

    Does anyone have a location for the latest and greatest versions of
    ROOT and SIMPLE_ROOT?  My SIMPLE_ROOT says it was linked on 5-May and
    from the notes above, it looks like changes were made to ROOT after
    that.
    
    .68 states that the "quota exceeded" problem in ROOT is cause by BYTLM. 
    For some reason or another mine is set to 1500000 and it still doesn't
    work.
    
    Has anyone figured out the necessary UAF/SYSGEN parameters to run ROOT
    properly?
    
    -joe tomkowitz

>             <<< Note 158.81 by JOET::JOET "Question authority." >>>
>    Does anyone have a location for the latest and greatest versions of
>    ROOT and SIMPLE_ROOT?  My SIMPLE_ROOT says it was linked on 5-May and
>    from the notes above, it looks like changes were made to ROOT after
>    that.

My versions report a link date of..
ROOT         25-MAY-1989 08:59
SIMPLE_ROOT   5-MAY-1989 15:36
    
>    .68 states that the "quota exceeded" problem in ROOT is cause by BYTLM. 
>    For some reason or another mine is set to 1500000 and it still doesn't
>    work.
>    Has anyone figured out the necessary UAF/SYSGEN parameters to run ROOT
>    properly?
    
You may want to increase Pgflquo.. ROOT works for me and my profile
looks like this..

Maxjobs:         0  Fillm:        60  Bytlm:       360000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:       100  JTquota:       1024
Prclm:           6  DIOlm:       100  WSdef:          350
Prio:            4  ASTlm:        80  WSquo:         5000
Queprio:         0  TQElm:       100  WSextent:     15000
CPU:        (none)  Enqlm:       200  Pgflquo:     300000

    Peter,
    Have you tried ROOT on DECwindows V2 (VMS 5.3)?  I'm getting several
    'not a valid window ID' errors from the server *every* time I run ROOT
    (or SIMPLE_ROOT).  The image does (usually) appear in my root window,
    but the error messages (and tracebacks) are annoying...
    
    Also, using /FULL on an image smaller than my screen tends to abort,
    claiming that the scaled-up image is now too big for my screen!  It's
    working fine for scaling images down though, just what I was looking
    for.  Thanks!

    Sample error report follows...

    ( from SIMPLE_ROOT )
%PEB-I-LINKDATE,  5-MAY-1989 15:36
X error event received from server:  not a valid window ID
  Failed request major op code 15 (X_QueryTree)
  Failed request minor op code 0 (if applicable)
  ResourceID 0x1000c3 in failed request (if applicable)
  Serial number of failed request 92
  Current serial number in output stream 92
%XLIB-E, error event received from server
%TRACE-E, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC
                                                           00767670 00767670
                                                           00767495 00767495
                                                           00768DE3 00768DE3
                                                           00768204 00768204
                                                           0077D909 0077D909
.MAIN.          FIND                                       00000043 000F5E77
.MAIN.          IMAGE                                      00000383 0001BCB7
                                                           7FED79D7 7FED79D7
                                                           0001B282 0001B282
.MAIN.          START                                      000000C3 0001B92E
... 129599 data bytes read from bitmap file
........... Performing SCALE..............
 Image will be scaled by      0.889
Read of bitmap file complete
 ELAPSED:    0 00:01:10.77  CPU: 0:00:55.69  BUFIO: 5  DIRIO: 83  FAULTS:1140
Image details  (Height 800     Width 1024)
X error event received from server:  not a valid window ID
  Failed request major op code 2 (X_ChangeWindowAttributes)
  Failed request minor op code 0 (if applicable)
  ResourceID 0x8006b in failed request (if applicable)
  Serial number of failed request 108
  Current serial number in output stream 112
%XLIB-E, error event received from server
%TRACE-E, symbolic stack dump follows
	.
	.
	.

    The .XBM files referred to earlier have moved from UKCSSE::SYS$PUBLIC:
    to BULOVA::SYS$XBM: as a temporaruy expedient. If anyone has 100k
    blocks spare to use as a public directory, please copy 'em over and let
    me know so that I can freee up the space on BULOVA::. Ta.
    
    Andy

    After reading all of the responses to this note, has any one developed
    a version of root that will run under ULTRIX. Specifically RISC ULTRIX.
    
    I have a DS2100, and I would like to be able to use this utility.
    
    Thanks in advance.
    
    Paul R. Haust

Re/ .85:

There's already a utility on Ultrix for setting the root window bitmap.
 It's called xsetroot.  It should be in /usr/bin/X11 normally.   You just say:

xsetroot -bitmap file.bitmap

and it chugs away.  This can also be used to set the background to a solid color.

In order to get the MIT stuff installed, you need to install the UDXUNMIT400
subset or its equivalent for whatever UWS version you're running.
				Jeff

                       <<< Note 158.86 by DAVIS::peter >>>
                            -< It's there already >-
    
    What about an ULTRIX utility that stuffs DDIF files on the background
    window?
    
    Thanks,
    
    	 	== ken miller ==

    How about reading the DDIF file you want to display into dxpaint and
    saving it in X11 bitmap format ?
    
    This would allow you to use the image with xsetroot.
    
    Joe.
    

I think the reason for going from DDIF directly should be obvious...IT'S MUCH
FASTER.

Dick

RE: Note 158.88 by GOLLY::MILLER
>    
>    What about an ULTRIX utility that stuffs DDIF files on the background
>    window?

RE: Note 158.89 by VOGON::DRUMGOOLE
>    How about reading the DDIF file you want to display into dxpaint and
>    saving it in X11 bitmap format ?
>    
>    This would allow you to use the image with xsetroot.


Why not just use UTOX? It works on VMS, VAX ULTRIX and RISC ULTRIX.  It can
read DDIF, Xbitmap, MSpaint, MacPaint, GIF, FSE, UIS images, and sixels and
put them on your root window background or even your pause screen window.
Plus, it does a whole lot more.

Check it out.  CLOSET::UTOX (note #2 for kit info).

-Mike

I can't get JUNO""::ROOT.EXE. There is nothing on Juno"::.
Anybody know where the new location is for root.exe?

/lalit

I have a ROOT.EXE on my WS. You can copy it form

	SIRENA::USER:[DEMICO.ROOT]ROOT.EXE 

(%PEB-I-LINKDATE, 25-MAY-1989 08:59
Peter Bailey's  (JUNO::BAILEY) version of XSetRoot)

CIAO
Anto