Conference bulova::decw_jan-89_to_nov-90

    	I'm realtively new as a DECWindows user, but so far,,,
        as much as I know, The watch is the 'wait' indicator.


    
    It stays on the screen while a task is starting up, or in progress
    on the window where the task was requested.  Move the mouse off
    the window, the watch turns back to your pointer, move the mouse
    back to the window where a task is in progress the watch comes
    back..
    
    The session manager has a CUSTOMIZE option, in which you can change
    DECWindow attributes.  (Window, Pointer, Keyboard, PRint screen, etc..)
    The watch would/should exist in that sub-menu if it was a available
    option. 
    
    

    I had put similar code in the old conference, here is an updated
    version:
    
    cur_font = XLoadFont(i_display, "DECw$Cursor");
    sts = XAllocNamedColor(i_display, i_dmap, "White", &cur_bc, &cur_dmy);
    sts = XAllocNamedColor(i_display, i_dmap, "Red", &cur_fc, &cur_dmy);
    wait_cursor = XCreateGlyphCursor(i_display, cur_font, cur_font,
            decw$c_wait_cursor, decw$c_wait_cursor+1, &cur_fc, &cur_bc);

    XDefineCursor (i_display, image_window, wait_cursor); /* set watch */
    XUndefineCursor (i_display,image_window);             /* remove watch */


						Enjoy,
                                                -Dave

    Oh yes, unfortunately there doesn't seem to be a "C" binding for
    the DECwindows cursors.
    
    #include <sys$library/DECw$Cursor.h>
    
    That will get the VAX binding version, hopefully this oversight
    will be corrected in the next DECwindows release (should I QAR this?).
    
    						-Dave

    QAR's are always better submitted, then rejected, than not submitted at
    all, to the customers detriment.
    
    Andy

Putting up a watch cursor is a good way to signal to the user that needs to
wait. How then do you ignore the events that happen while the watch cursor is
displayed?

    The idea is that you display the "wait" cursor when you are not
    in a position to handle events.  Once you are event handling it
    should no longer be displayed.
    
    Usually an event that triggers a lot of CPU processing is cause
    to display the "wait" cursor.  When the processing is over and
    you are about to return to event processing you disable the "wait"
    cursor which allows the "normal" cursor to re-appear.
    
    I think the style guide goes into more detail, not positive.
    
    						-Dave

    There's nothing magic about the "wait cursor" - your application
    turns it on and off when it wants to.  It's up to your application
    to decide how to handle events that occur while you are "waiting".
    
    				Steve

    
    
    
    
    If this is a toolkit application, you can enable the same filtering
    of events that modal dialog boxes use (for example work in progress
    boxes).  Example code is included below.
    
    Leo
    
    
/*
 *  This routine displays a cursor, and initiates toolkit filtering
 *  of input events
 */

WorkCursorDisplay (cursor_wid, grab_wid, cursor)
    Widget  cursor_wid;		/*  Widget to display wait cursor in
				    (Usually application main window) */
    Widget  grab_wid;		/*  Widget to use in call to XtAddGrab.
				    This widget will be the only widget
				    to have all events passed to it.
				    It is easiest to use an unmapped
				    widget.*/
    Cursor  cursor;		/*  Cursor to display */
{
/*
 *  Use XDefineCursor to set the window to the supplied cursor
 */
    XDefineCursor(XtDisplay(cursor_wid), XtWindow(cursor_wid), cursor);

/*
 *  Use XtAddGrab to enable toolkit filtering of events
 */
    XtAddGrab(grab_wid, TRUE, FALSE);
}



/*
 *  This routine un-displays a cursor, and terminates toolkit filtering
 *  of input events
 */

WorkCursorRemove (cursor_wid, grab_wid)
    Widget  cursor_wid;		/*  Same two widgets used in call to
				    WorkCursorDisplay */
    Widget  grab_wid;		
{
/*
 *  Use XUndefineCursor to undo the cursor
 */
    XUndefineCursor(XtDisplay(cursor_wid), XtWindow(cursor_wid));

/*
 *  Use XtRemoveGrab to disable toolkit filtering of events
 */
    XtRemoveGrab(grab_wid);
}
    
    

    Please note that the XUI Style Guide recommends a black and white wait
    cursor.

    Tracy

    I think the session manager uses the window highlight color and
    the screen foreground color (my highlight color is red).  This may
    indeed be a bug, but I was using the session manager as a guide
    figuring the style guide might have been outdated.  Note that
    the session manager lets one set the pointer color, in my case
    it is yellow and black, neither color is used by the wait cursor.
    
    						-Dave

    re: 10
    
    	The watch is always red.  None of the colors I use in my setup
    are red or white (the 2 colors used for the watch).
    
    
       				Tony
    				

	I haven't seen it written officially anywhere, but all DECwindows
	layered products are using a red and white wait cursor.  The color
	is controlled from the application that defines it.

	-ric.

    Using the code posted early, works, but I seemed to have to do a
    XSync (after the XDefineC...) to get the watch to show up reliably.  
    Is this the proper thing to do?
    
    Thanks much,
    
    Ken B.

    Re: .12

    See Figure 7-2 in the XUI Style Guide.

    Tracy

	RE: -2

	No, do not use XSync.  This is used primarily for debug.  It
	causes the X Server and the client program to operate synchronously
	by waiting till all requests are received by the X Server.

	If you use XSync, your program will run slowly.  What you need to
	do is replace your XSync call with XFlush, which will flush the
	output buffer, but won't wait till all requests are received by
	the X Server.  This will give you the behavior you're looking
	for.

	-ric.

>	No, do not use XSync.  This is used primarily for debug.  It
>	causes the X Server and the client program to operate synchronously
>	by waiting till all requests are received by the X Server.
>
>	If you use XSync, your program will run slowly.  What you need to
>	do is replace your XSync call with XFlush, which will flush the
>	output buffer, but won't wait till all requests are received by
>	the X Server. 


I think you're confusing XSync and XSynchronize.   XSynchronize causes
synchronous operation of server and client, and is the one intended for
debug use.  XSync is a one-shot flush-and-wait operation, so doesn't 
in itself cause your program to "run slowly".

XFlush could still be the right choice in this particular situation,
though.  

	Dave,

	You're right!  I should know better.  That was an oversight on my
	part...  Sorry if I confused anyone.

	But I would still recommend XFlush in this situation...

	-ric.

Geesh, the only code I write and it's got two bugs.  I think the XFlush
is probably as good as Xsync, I don't remember the reason for using Xsync.

The "red" is supposed to be black.  I wrote the code before there was a
SG decision.

It's red everywhere because everyone has copied the same fragment of code,
which was originally done for Print Screen in the session manager.

Note that I am suitably embarrassed about this.

    Thanks very much for the XFlush suggestion, and for the original
    code, as well.
    
    Now, let's see if my tired old brain has this right:
    
    The wait cursor should ALWAYS be black on white.  NOT current window
    foreground on current window background.
    
    Is that correct?
    
    Thanks again,
    
    Ken B.
    

One fortunate mistake.

I like red better than black...

Chad

	RE: .18

	Jake,

	Should DECwindows layered products be using the black on white
	wait cursor?  Or should we continue with tradition and use the
	red on white one?

	Thanx,

	-ric.

    My vote is to continue tradition, I like the red on white as well.
    
    						-Dave

... I'd much prefer to see the red and white watch.

   I find that the "red on white" watch is more visible and a better clue to
the "waiting" state that the application is in than the black-on-white watch
cursor.  I can't think of what application it is that uses the black-on-white,
but I find the red watch more informative "at a glance".

   Perhaps someone from the XUI group who made the original "black on white"
decision could comment?


					-mjg

       
       
       
       	The DDIF viewer uses black and white.. So does FLIGHT. :-)
       
       							mike

    The first time I saw a red and white watch cursor I didn't immediately
    know what it was because of the low contrast between red and white.  Red
    isn't a very realistic color for a watch - black is much better.

    Tracy

re .-1

Yeah, I agree.   Red on white is pretty wishy-washy.

Actually, an hourglass seems more recognizable that a wristwatch.
Those with 6MB VS2000's would probably think it more appropriate anyway!

I did alot of things that make a watch appear...  like open this conference...

I like the watch...

black seems better than red for color, but even black doesn't see to
attract my attention enuf...

how about BRIGHT yellow with a black border...

just thinking....

       
       
       
       	What happens if you are color-blind? Red, yellow, green might not
       	help much.. (I dunno myself. I'm just nearsighted as all hell)
       
       	For me, I prefer the black&white because I DO color my pointer
       	and all my windows.. Black&white tells me something is different.
       
       							mike

    Yeesh... you can make it mauve on paisley, for all I could tell - I've
    got a black+white system.
    
    Seriously, don't choose a color set that will be unreadable on
    monochrome or intensity systems.
    
    					Steve

...seems to me that the solution is to add the watch cursor color choice to
the session manager's Customize pull-downs somewhere.  At least that's where
I went when I got tired of red-on-black.

The whole purpose of the XUI style guide was so conversations like this wouldn't
happen.  I think if the trouble was made to create such a book, the applications
should stick to it.  (And this is a person who likes the red watch better).

I am puzzled though, of why the guide does say black on white, yet all the
DECwindows applications but the DDIF view use the red????

oh, and this is to reply .25 (or maybe .26) on the realizm of a red watch.

   - I think if I was going to make a real watch half the size of a dime, I 
     would definatly make it red ;^)


		$$$$ ted $$$$

    DECwrite in the FT2 baselevel doesn't use yellow on black for the
    normal pointer, and the watch is black on white if I remember
    correctly.  The "inactive" pointer is supposed to be red on white
    according to the style guide.
    
    I tend to agree with what was said earlier about it should be
    customizable.  Note that the style guide is just that, a "guide".
    It probably should have been called the style "standard" instead,
    if that is what it is truly intended to be.  If the goal is to
    eliminate discussions like this one then their really should be
    a "DEC standard" published internally!  I think the "standard" should
    say "thou shalt make thy cursor pointer color customizable".  And
    while we are at it "thou shalt make thy application window positions
    [and sizes where applicable] customizable".
    
    I'll relinquish the soapbox now!
    
    						-Dave

Seeing as there is a conference for discussing what ought to be in the style
guide, why not continue the discussion there?

Also, it's a guide because it was recognized that there would be many
instances in which the recommendations would not be applicable.  However,
without overriding justification we should treat its guidelines as standards.

Now I can get off of my soapbox  8^{).

Dick

.-1 is probably right, but I've been meaning to ask...

Why doesn't  it just follow the pointer's color? I chose my pointer color to
be  highly visible, and would just as soon have the watch be the same color.
That's  certainly  bettr  than having black be the default (particularly for
people who have black as their default window background...)

- Brad