Conference bulova::decw_jan-89_to_nov-90

RE: .0

>    How to use UIL to create a window widget whose visual type is different
>    from its parent's?  If there's no such UIL routine to do this, how
>    about Xtoolkit?  Is there any routine could be used to set visual type
>    of an existing window?

You can't do this with the currently released DECwindows software because there
is no way in the Xtoolkit R3 Intrinsics to specify a non-default visual for
Toolkit windows.  This problem is corrected in the R4 Intrinsics.

    Thanks.
    
    Does VS3520 has to be true color visual type if it has 24 planes?
    
    Is there any way to implement what customer needs? That is, to divide
    16 color planes into two groups. One group is to show map while the
    other display graphics symbols?
    
    Johnny

    To be more specific, you can't do it with any of the "built-in"
    widgets.  You can write your own widget that does this.  Here is
    an example of a subclass of the XUI window widget:
    

#define XWINDOW
#include <decw$include/decwdwtwidgetprog.h>
#include "xwindow.h"

/* static declaration of the class record */
/* external def is a macro to handle      */
/* definitions of global vars             */

externaldef(xwindowwidgetclassrec)
WindowClassRec xwindowwidgetclassrec = {
  {
    /* superclass	  */	(WidgetClass) &windowwidgetclassrec,
    /* class_name	  */	"Different_visual_window",
    /* widget_size	  */	sizeof(WindowWidgetRec),
    /* class_initialize   */    NULL,
    /* class inited part  */    NULL,
    /* class_inited       */	FALSE,
    /* initialize	  */	NULL,
    /* initialize hook    */    NULL,
    /* realize		  */	Realize,
    /* actions		  */	NULL,
    /* num_actions	  */	0,
    /* resources	  */	NULL,
    /* num_resources	  */	0,
    /* xrm_class	  */	NULLQUARK,
    /* compress_motion	  */	FALSE,
    /* compress_exposure  */	FALSE,
    /* compress enter/exit*/    FALSE,
    /* visible_interest	  */	FALSE,
    /* destroy		  */	NULL,
    /* resize		  */	XtInheritResize,
    /* expose		  */	XtInheritExpose,
    /* set_values	  */	NULL,
    /* set values hook    */    NULL,
    /* set values almost  */    XtInheritSetValuesAlmost,
    /* get values hook    */    NULL,
    /* accept_focus	  */	NULL,
    /* version            */    XtVersionDontCheck,
    /* callback list      */    NULL,
    /* default trans      */    NULL,
    /* query qeometry     */    NULL,
    /* disp accelerators  */	NULL,
    /* extension          */    NULL,
  },
  {					/* composite class record */
    /* geometry mgr proc  */	XtInheritGeometryManager,
    /* set changed proc   */	XtInheritChangeManaged,
    /* add a child        */	XtInheritInsertChild,
    /* remove a child     */	XtInheritDeleteChild,
    /* extension          */    NULL,
  },
  {					/* dwt common class rec*/
    /* Pad0 	          */	_XtInherit,
    /* Pad1 	          */	_XtInherit,
    /* Pad2 	          */	_XtInherit,
    /* extension          */    NULL,
  },
  {                                     /* window class record */
    /* extension          */    NULL,
  }

};

/* this is the pointer to the widget's class */

externaldef(xwindowwidgetclass)
WindowClass xwindowwidgetclass = &xwindowwidgetclassrec;



/* this routine is called when the widget is to */
/* be realized                                  */

static void Realize(w,valuemask,attributes)
    Widget               w;
    Mask                 *valuemask;
    XSetWindowAttributes *attributes;
{
    WindowWidget ww;

    ww = (WindowWidget) w;

/* CHANGE HERE!!!  Replace CopyFromParent with the visual you want */
    XtCreateWindow(w,InputOutput,CopyFromParent,*valuemask,attributes);
}

Widget WindowCreate (parent,name,arglist,argCount)
       Widget parent;
       char   *name;
       Arg    *arglist;
       int    argCount;
{
    return (XtCreateWidget(name,xwindowwidgetclass,parent,arglist,argCount));
}

   =================================================================
    
    window.h
    

/*************************************************************************
 *
 * window widget
 */

typedef struct 
{
    int	junk;
} 
    XWindowPart;

typedef struct 
{
    CorePart		    core;		/* basic widget */
    CompositePart	    composite;		/* composite specific data */
    DwtCommonPart	    dwtcommon;
    WindowPart		    window;
    XWindowPart		    xwindow;
} 
    XWindowWidgetRec, *XWindowWidget;


typedef struct
{
    caddr_t		extension;	/* Pointer to extension record */
}
    XWindowClassPart;


typedef struct _XWindowClassRec 
{
    CoreClassPart	    core_class;
    CompositeClassPart	    composite_class;
    DwtCommonClassPart	    dwtcommon_class;
    WindowClassPart	    window_class;
    XWindowClassPart	    xwindow_class;
} 
    XWindowClassRec, *XWindowClass;


#ifndef XWINDOW
external XWindowClassRec     xwindowwidgetclassrec;
external XWindowClass        xwindowwidgetclass;
#endif


    
    

I'm not sure I understand the business about dividing planes.  However,
I can say that the 35x0 with 24 planes must have TrueColor as the default
visual.  All 24-plane 35x0's can also get a 24-plane DirectColor visual and
an 8-plane PseudoColor visual, though.

You did not say anything about the customer having to write to any of the
colormap cells.  This would be the only reason why s/he should need something
other than TrueColor.  (Or if s/he needs to put certain colors in certain
locations.)

Burns

    > The map data it would display requires 12 color planes. Besides
    > displaying map, it also has to display some graphics symbles which has
    > 15 different colors. So another 4 planes is required. They intend to
    > divide 16 color planes into two group. One group is used to show map
    > while the other display graphics symbles. Is this idea feasible on a
    > true color VS3520?  

    If I understand the customers application correctly, the VS3520 can't
    do what the customer wants.  It appears that you would need a system
    that supported a 16 plane PseudoColor visual.

    Let me try to describe what the customer wants to do.  First they
    allocate 12 planes for the map.  They can then draw the map into the
    pixmap once and never change it.  Since they also want to draw some
    symbols in 15 colors over top of the map, they need to allocate 4
    planes out of a pseudoColor visual to allow them to do a CopyPlanes
    call to copy the symbols from a 4 bit pixmap to the map pixmap without
    touching any of the bits in the 12 map planes.  This would allow
    the symbols to be changed many times without ever having to redraw
    the map planes.  To do this the customer would have to fill 4096 color
    table entries with the colors that the map would use and the other 61440
    color table entries with the 15 symbol colors with each color taking
    up 4096 entries.  

    This scheme would work if the VS3520 was a 24 bit pseudoColor system,
    it's not.  It is a 24 bit true color system.  In a TureColor system
    there is no color table.  You can't divide the color planes up for
    dedicated use.  Each number that you could put into a 24 bit deep
    pixmap corresponds to a fixed color.  You can't make a fixed pixel
    value cause a predefined color to appear.  If you tried your scheme on
    the 24 bit TrueColor system you would see the map in all the wrong
    colors overlaid by symbols that are a different color from the map
    but the color of each pixel in the symbol will depend on the color of
    the map at that pixel.


    						MJC

    
    Ah, the FireFox (35x0) supports a DirectColor visual... so they can
    divide up 24 planes.  In fact, the TrueColor visual is implemented
    by loading a fixed Direct map.
    
    

    Boy, am I glad to have your responces!
    
    Re .5
      Yes, it is exactly what they want to do!
    
    Re .6 
      Can't tell you how happy they are when they know FireFox supports
      DirectColor visual!
    
    Thank you all!

    Re .5:  Ah..I understand.  Thanks.  But re .6:  Allocating planes out
    of a direct color visual can be done, of course, but you have to choose
    your planes carefully, and you may need more than 4 to get the 15
    colors you want.  For example, in order to get 15 totally random
    colors, you need to allocate 4 planes from each of red, blue and green
    fields.  If you can carefully decide just what colors you need, you
    may be able to get away with not allocating from every field.
    
    BTW, you need to use XAllocColorPlanes for this.  (XAllocColorCells
    with planes specified will only allocate triplets of RGB planes).  This
    has been used very little in the history of the world.  Keep the
    SPR/QAR pencil handy, and don't forget to include sample code!
    
    Burns