jonm@syma.sussex.ac.uk (Jonathan Meyer) (08/14/90)
I want to add a converter in Xt for the backgroundPixmap, that takes a string (bitmap file) and creates a pixmap of the correct depth for the window, with two colours (foreground and background). This is much harder than it seems! Because there is no foreground_pixel in the Core widget, I can't think of a good way of doing this - when the converter is being run it doesn't know what foreground colour to use, because the foreground resource hasn't been set yet. All it can do is create a black and white pixmap. One solution would be for the converter to create a pixmap of depth one (ie a bitmap), and the widget initialize procedure to then turn this bitmap into a pixmap of the correct depth and colours. The difficulty with this is that the initialize procedure doesn't know the width and height of the bitmap so it can't easily convert it to a pixmap of the same size, but with a different depth. Can someone tell me of an easy way to solve this ? Is there some (undocumented) technique for finding the size of a pixmap? Or is there some other clever trick I can employ? At the moment, I am resorting to using a hash table keyed on pixmaps, storing their dimensions. Of course, this hash table is only examined for widgetclasses that I have written, so the converter is useless for any other widgetclasses :-( Jon.
adri@dutncp8.tudelft.nl (Adri van Woerkom (A.B.)) (08/16/90)
jonm@syma.sussex.ac.uk (Jonathan Meyer) writes: >Can someone tell me of an easy way to solve this ? Is there some >(undocumented) technique for finding the size of a pixmap? When XGetWindowAttributes is called with a Pixmap id as second parameter (instead of the window id) the width, height, depth and screen members of the returned XWindowAtributes structure are filled in (all others will return 0). ---------------------------------------------------------------------------- A.B. van Woerkom, adri@dutncp6.tudelft.nl Faculty of Applied Physics, Department Physics Informatics, section Computational Physics, Delft University of Technology, Delft, The Netherlands -----------------------------------------------------------------------------
mouse@LARRY.MCRCIM.MCGILL.EDU (08/16/90)
> Is there some (undocumented) technique for finding the size of a > pixmap? XGetGeometry is documented as working for windows or pixmaps. I haven't tried it but I would certainly expect it to behave. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
asente@adobe.com (Paul Asente) (08/17/90)
In article <3254@syma.sussex.ac.uk> jonm@syma.sussex.ac.uk (Jonathan Meyer) writes: >I want to add a converter in Xt for the backgroundPixmap, that takes a string >(bitmap file) and creates a pixmap of the correct depth for the window, with >two colours (foreground and background). This is much harder than it seems! >Because there is no foreground_pixel in the Core widget, I can't think of >a good way of doing this - when the converter is being run it doesn't know >what foreground colour to use, because the foreground resource hasn't been set >yet. All it can do is create a black and white pixmap. You can do this, but it's not terribly pretty. Step 1: Define your string-to-pixmap converter, and pass the foreground and background in as conversion arguments. The converter argument should be of type XtResourceString, so the appropriate arguments are {XtResourceString, XtNforeground, sizeof(Pixel)}, {XtWidgetBaseOffset, XtOffsetOf(WidgetRec, core.background_pixel), sizeof(Pixel)} (see, those other converter arg types are good for something!) Specifying the arg as XtResourceString means that this converter can be used in different widget classes that may not all have XtNforeground in the same place in the widget record. Step 2: Define a new widget field and resource that will hold the result of the conversion. Rather than specifying the background pixmap, specify this resource. The resource list entry for this must occur *after* the entry for XtNforeground, otherwise the converter won't be able to use the foreground. Step 3: In your initialize procedure, if this new resource field is not None, copy it into the core.background_pixmap field. -paul asente New address! asente@adobe.com ...decwrl!adobe!asente
klee@wsl.dec.com (Ken Lee) (08/21/90)
In article <adri.650791583@dutncp8>, adri@dutncp8.tudelft.nl (Adri van Woerkom (A.B.)) writes: |> When XGetWindowAttributes is called with a Pixmap id as second parameter |> (instead of the window id) the width, height, depth and screen members |> of the returned XWindowAtributes structure are filled in (all others |> will return 0). This may work with some implementations, but is non-standard. XGetWindowAttributes is only guaranteed to work on windows. To get info on pixmaps, use XGetGeometry. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
adri@dutncp8.tudelft.nl (A.B. van Woerkom) (08/21/90)
klee@wsl.dec.com (Ken Lee) writes: >In article <adri.650791583@dutncp8>, adri@dutncp8.tudelft.nl (Adri van Woerkom >(A.B.)) writes: >|> When XGetWindowAttributes is called with a Pixmap id as second parameter >|> (instead of the window id) the width, height, depth and screen members >|> of the returned XWindowAtributes structure are filled in (all others >|> will return 0). I had this from the O'Reilly Xlib Reference Manual, Third Printing, May 1989. >This may work with some implementations, but is non-standard. >XGetWindowAttributes is only guaranteed to work on windows. To get >info on pixmaps, use XGetGeometry. If this is the case a there should be some warning in the next edition of the named reference. ________________________________________________________________________ A.B. van Woerkom, adri@dutncp6.tudelft.nl Delft University of Technology, Faculty of Applied Physics, Department Physics Informatics, section Computational Physics, Lorentzweg 1, 2628 CJ DELFT, The Netherlands ________________________________________________________________________
ekberg@ti-csl.csc.ti.COM (08/22/90)
adri@dutncp6.tudelft.nl (A.B. van Woerkom) writes: > klee@wsl.dec.com (Ken Lee) writes: > > > >In article <adri.650791583@dutncp8>, adri@dutncp8.tudelft.nl (Adri van Woerkom > >(A.B.)) writes: > >|> When XGetWindowAttributes is called with a Pixmap id as second parameter > >|> (instead of the window id) the width, height, depth and screen members > >|> of the returned XWindowAtributes structure are filled in (all others > >|> will return 0). > > I had this from the O'Reilly Xlib Reference Manual, Third Printing, May > 1989. > > >This may work with some implementations, but is non-standard. > >XGetWindowAttributes is only guaranteed to work on windows. To get > >info on pixmaps, use XGetGeometry. > > If this is the case a there should be some warning in the next edition of > the named reference. The GetWindowAttributes request does not return the width, height or depth even if it is passed a window as its argument. The GetGeometry request takes a drawable (a window or pixmap) as its argument and returns the width, height and depth, as well as some other values. In the X11R4 protocol specification, see pages 15-16 for the description of GetWindowAttributes and page 20 for the description of GetGeometry. The confusion seems to be that the Xlib XGetWindowAttributes function returns a pointer to an XWindowAttributes structure, which does have slots for width, height and depth. What this means is that to obtain this information the XGetWindowAttributes function invokes both the GetWindowAttributes request, which works only for a window, and the GetGeometry request which works for either a window or a pixmap. In the source (mit/lib/X/XGetWAttrs.c), the GetWindowAttributes request is called unconditionally which will cause the server to generate a Window error if the user attempts to pass a pixmap as its argument. -- tom (aisle C-4Q), ekberg@csc.ti.com