Conference bulova::decw_jan-89_to_nov-90

#include <stdio.h>
#include <decw$include/DwtWidget.h>
#include <decw$include/Vendor.h>

#define MAXARGS           4

static XtCallbackProc ButtonArmed(),
                      ButtonActivated();
static XtEventHandler CheckIconState();

static DwtCallback arm_callback[] = {
                      {ButtonArmed, NULL},
                      {NULL, NULL}
                   },
                   activate_callback[] = {
                      {ButtonActivated, NULL},
                      {NULL, NULL}
                   };

Atom icon_state_atom;

main(argc,argv)
   unsigned int argc;
   char *argv[];
{
   Widget top_level,push_button;
   Arg args[MAXARGS];
   int n;

   /* Initialize the toolkit, and create the top-level widget */

   top_level = XtInitialize("Hi!","Example",NULL,0,&argc,argv);

   n = 0;
   XtSetArg(args[n],DwtNx,340);                ++n;
   XtSetArg(args[n],DwtNy,288);                ++n;
   XtSetArg(args[n],XtNallowShellResize,True); ++n;
   XtSetValues(top_level,args,n);

   /* Get the icon-state atom */

   icon_state_atom = XInternAtom(XtDisplay(top_level),
                                 "DEC_WM_ICON_STATE", /* Property name */
                                 FALSE);              /* only_if_exists? */

   /* Install an event handler to check property changes */

   XtAddEventHandler(top_level,PropertyChangeMask,False,CheckIconState,0);

   /* Create push-button widget using low-level interface */

   n = 0;
   XtSetArg(args[n],DwtNarmCallback,arm_callback);                ++n;
   XtSetArg(args[n],DwtNactivateCallback,activate_callback);      ++n;
   XtSetArg(args[n],DwtNshadow,False);                            ++n;
   XtSetArg(args[n],DwtNlabel,DwtLatin1String("Hello, World!"));  ++n;

   push_button = DwtPushButtonCreate(top_level,"pushButton",args,n);

   XtManageChild(push_button);

   XtRealizeWidget(top_level);

   XtMainLoop();  /* Never returns */
}

static XtCallbackProc ButtonArmed(widget,tag,reason)
   Widget widget;
   char *tag;
   DwtAnyCallbackStruct *reason;
{
   Arg arg;

   XtSetArg(arg,DwtNlabel,DwtLatin1String("Goodbye, World!"));
   XtSetValues(widget,&arg,1);
}

static XtCallbackProc ButtonActivated(widget,tag,reason)
   Widget widget;
   char *tag;
   DwtAnyCallbackStruct *reason;
{
   exit(1);
}

static XtEventHandler CheckIconState(widget,closure,event)
   Widget widget;
   caddr_t closure;
   XPropertyEvent *event;
{
   WmIconStateRec icon_state_rec;
   Arg arg;

   if (event->type == PropertyNotify) {
      if (event->atom == icon_state_atom) {

         XtSetArg(arg,XtNiconState,&icon_state_rec);
         XtGetValues (widget,&arg,1);

         printf("Application state: %s\n",
                icon_state_rec.state == WmNormalState ? "normal"
                                                      : "iconic");
      }
   }
}

    Re .1
    
    Thanks for the speed and quality of the reply. It looks good.

    Frank

    I have been able to turn off/blacken out these three buttons that 
    appear on the title banner of the windows.  What I am trying to do
    'disable' the grab and move of windows that still have the title
    banner.
    
    Does anyone know if this can be done??
    
    ADVthanksANCE
    
    				-=> Jim <=-
    

    What do you mean by "disable grab and move of windows".
    
    The window manager passive grab I assume is the grab
    you want to disable?
    
    What about this disable move of windows?
    
    Are you trying to eliminate window manager involvement
    entirely?  If so,  override redirect windows would
    work - you wouldn't get a title bar.

    Maybe I want to have my cake and eat it too.
    
    I would possibly like to prevent the user from moving windows but
    still have some window manager control, i.e. not use override
    redirect.
    
    Now, if I do use the override redirect what kind of things do I want
    to watch out for?  In other words, what does the window manager do for
    me that I will now have to do myself?
    
                               -=> Jim <=-
    

>>    I would possibly like to prevent the user from moving windows but
>>    still have some window manager control, i.e. not use override
>>    redirect.

You could always keep your window from being moved by allowing it to
move, but immediately moving it back to where you think it should be.
Of course, many people would say that this is the behavior of an
anti-social application, but if you're really insistent...

There are two steps to this solution.  First you need to detect when the shell
has been moved away from its "proper" position, and then you need
to put it back where it belongs.

Let's assume that the window is in the proper position when it is first
mapped.  You could trap the MapNotify event on your shell widget and
then do an XTranslateCoordinates to figure out where on the screen the
window really is.  Save this as the "proper" position.  Remember that
the window manager may not even put the window where you want initially -
since there may be rules about initial visibility, etc.

Whenever the window manager moves an application's window, it sends
a client message to the affected shell widget.  Rather than counting
on the particular atom used as the client message type, I assume that
whenever I hear from the window manager, then the window might have
been moved.  Do another XTranslateCoordinates to see if the shell really
has moved, and if so, ask the window manager to move it back (by setting
x and y on the shell widget using XtSetValues).

The things you lose with override redirect include:

	iconification
	push-to-back
	resize
	movability
	bring to front on MB1 click
	nice borders
	assignment of focus (maybe)

-steve-

    is this a suggestion for
    
    Bool title_bar_has_no_move_semantics;
    
    to be added as a field to the DECWmHintsRec?

    
    
                  Wouldn't that be swell ?!?!?!
    
    
    

.7>    is this a suggestion for
.7>    
.7>    Bool title_bar_has_no_move_semantics;
    
    Nope, it's really a mask of movement in 3 dimensions: x, y, and z.
    The z dimension of course refers to the stacking of windows, i.e.,
    push-to-back and pop-to-front.  (Any calls for "direction" as well
    as "dimension"? :-)
    
      John