wdc@ATHENA.MIT.EDU (Bill Cattey) (10/19/90)
I've written compiled and tested my im_CreateTransient code. It works. It has a *bad* interaction with the existing Andrew dialogue boxes. My transient windows come up in front of the Andrew window. (They have to in order to be seen.) If an Andrew dialogue box comes up, it's text is obscured, but it grabs all the window events. This means that you can't see what action it's going to take, but you are forced to deal with it before you can deal with my Transient window. You can't even get rid of my transient, since there is no way an event to do so can get past the Andrew dialogue box. As I see it, there are two solutions: 1. Modify the event grabbing code of Andrew dialogue boxes to be less nasty to transients. 2. Rewrite Andrew dialogue boxes to use im_CreateTransient. My inclination is to throw away and rewrite the existing dialogue box code. I don't think I could quickly enough come to an understanding of the hair of the existing dialogue boxes. As I understand it, these dialogue boxes are of extremely limited functionality and should be easily replacable with new code. Everyone has been saying what a hairy crock the code is anyway. I believe the only real problem would come from the wm side of the fence. Is it possible for wm to create transient overlapping windows? If not, this could end up as a bad, user-visible change to the interface, and I don't want that. I guess a solution to such a problem would be to keep the old dialogue box code around conditionalized on the non-existance of transients. What do people think I should do? -wdc P.S. If anyone sent any design criticism, I've not received it. I'm flying blind here, and would very much like feedback.
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (10/19/90)
Excerpts from internet.info-andrew: 19-Oct-90 Issues in dialogue box crea.. Bill Cattey@athena.mit.e (1708) > 2. Rewrite Andrew dialogue boxes to use im_CreateTransient. > My inclination is to throw away and rewrite the existing dialogue box > code. I don't think I could quickly enough come to an understanding of > the hair of the existing dialogue boxes. As I understand it, these > dialogue boxes are of extremely limited functionality and should be > easily replacable with new code. Everyone has been saying what a hairy > crock the code is anyway. As the person who translated the dialog box code from bx to be2, I have to agree. Nuke it till it glows. > I believe the only real problem would come from the wm side of the > fence. Is it possible for wm to create transient overlapping windows? > If not, this could end up as a bad, user-visible change to the > interface, and I don't want that. Nuke wm till it glows, too.
dd26+@ANDREW.CMU.EDU ("Douglas F. DeJulio") (10/19/90)
Nathaniel Borenstein <nsb@thumper.bellcore.com> writes: > Nuke wm till it glows, too. NO! The "wm" program is much faster and smaller than X. I refuse to run X11, and if ATK no longer supported wm it would mean that I would have to stop using ATK. I don't want this to happen. -- Doug DeJulio
bader+@ANDREW.CMU.EDU (Miles Bader) (10/19/90)
Nathaniel Borenstein <nsb@thumper.bellcore.com> writes: > Nuke wm till it glows, too. No, don't.
datri@convex.com (Anthony A. Datri) (10/19/90)
>As the person who translated the dialog box code from bx to be2, I have >to agree. Nuke it till it glows. Hopefully making them stop clipping at the parent window border at the same time. -- datri@convex.com