wdc@athena.mit.edu (Bill Cattey) (10/16/90)
For more than a year, I have been turning over in my mind possible solutions to the problem: "ATK has limited, some say shitty, dialog box support". The fundamental limitation is that the dialogue boxes are drawn as an overlay bitmap on an existing im window. This means that it is hard to assemble a dialogue box out of ATK views. In fact, it is very hard to create a new im that would appear geometrically (geographically?) on top of an existing ez window, because the newly created im needs screen absolute coordinates, and the screen absolute coordinates of pre-existing windows are unavailable to children of the im. For a long time I wondered if there was some way to "cut into" the information stored about a window by the im, so that I could make a dialogue box im. But I think I have been inspired to a better solution than that. The real issue is that a dialogue box is a "pop-up on behalf of" another top-level window as the (ugh) X consortium ICCCM would say. It seems to me that the im should get a new call: im_CreateTransient(other); This would permit creating a top level window whose position is relative to the existing window (im actually) 'other'. This new call does change the im interface, by adding a new call, but does not expose the internal state, nor does it change any existing interfaces. Do people agree that this call should be added? I've got a printer-setup dialogue box (and two other application specific dialogue boxes) just waiting to use this call! I'll even write the change to im.c, and xim.c. -wdc
ajp+@andrew.cmu.edu (Andrew Palay) (10/16/90)
Yes this would be a useful addition to im. It will probably raise a bunch of other issues that will have to be resolved but starting down that path will indeed help. Andy