argv%turnpike@Sun.COM (Dan Heller) (04/10/90)
I know I can create an override-redirect shell using Xt, but what
if I want that to be my main window? I've ported my "nlock" program
to Xt from sunwindows, but I've run into a snag.
Basically, nlock is a "lockscreen" type program. I want to map a
window to the screen that disregards the window manager (e.g. does
not allow titlebars, etc) and grabs all pointer and keyboard input.
I know I can use code similar to a popup menu to create the window,
but I don't need all the other shells/widgets. I just want to
make the *toplevel* widget act this way. If I can't do that, how
about a reasonable workaround?
dan
-----------------------------------------------------------
O'Reilly && Associates
argv@sun.com / argv@ora.com
632 Petaluma Ave, Sebastopol, CA 95472
800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104
Opinions expressed reflect those of the author only.converse@EXPO.LCS.MIT.EDU (Donna Converse) (04/12/90)
> I know I can create an override-redirect shell using Xt, but what > if I want that to be my main window? ICCCM issues aside, set XtNoverrideRedirect to be True on the top level shell.
argv%turnpike@Sun.COM (Dan Heller) (04/12/90)
In article <9004111939.AA01109@expo.lcs.mit.edu> converse@EXPO.LCS.MIT.EDU (Donna Converse) writes: > > I know I can create an override-redirect shell using Xt, but what > > if I want that to be my main window? > ICCCM issues aside, set XtNoverrideRedirect to be True on the top > level shell. Nope -- didn't work. That is, I tried using a topLevelShellwidgetClass and set XtNoverrideRedirect to True and it made no difference. In looking thru code and doc to see why, I learned that that attribute is not intended to be set by the programmer or via resources -- it is an attribute that is set automatically by the internals to the shell widget code. Sorry, I don't remember the specifics for how I determined that... But, I didn't pay too much attention because at just about the same time I found XtAppCreateShell() and the shell class: overrideShellwidgetClass worked with the worked just fine. Now, to have my application consist entirely of a single override shell with a plain core widget underneith it, I simply ignore the toplevel shell returned by XtInitialize() and just use the new override shell as my toplevel shell. In order for that shell to get keyboard input, I must call XSetInputFocus() (or related call). Simply specifying in my translation table: <KeyPress>: function() didn't accept keyboard input for my simple core widget as it would for any other widget. (I tried setting XtNinput to both True and Flase on the override shell and false and neither worked.) Several other things I noticed... * There is no XtVa (varargs) version for XtAppCreateShell(). * "App" has nothing to do with this function call -- you don't specify any application context in its parameter list. Am I missing something? * There doesn't seem to be any way to specify shell-specific resources via XtInitialize(). Yes, you can use the "options" parameter, but this isn't quite the same thing as the Arg lists used in the other XtCreateWidget-style calls. Why not have the "args" and "nargs" parameters to XtInitialize (et al.) routines? Other related problems... Since this is a "lockscreen" program, there are clearly some nonstandard issue to consider. Thus, the reason for using an override-redirect shell. I do not want the window manager to know about this window (which means that the user should have no way of bringing up other windows over it). However, if an application underneith somehow does an XRaiseWindow(), I want to know about this an raise my lockscreen application back to the top again... To do this, I wanted to set VisibilityNotify in my translation table. Well, I noticed that I actually get the event at the first time the widget is mapped to the screen, but it is never called again regardless of the visibility events that may or may not get generated... If visibility events are not generated, I've found that the reason is that the override shell has save-under turned on and the server is repainitng any damaged window areas without notifying the application of a repaint or visibility event. I tried turning it off by setting XtNsaveUnder to False, but (like XtNoverrideRedirect) it had no effect. So, what other ways are there to turn off the save under? I not only want to, but (due to the nature of the activity in the window) I *have* to redraw the damaged areas of the window myself. This isn't working quite right... I have not been able to get visibility events to get generated at all and I'm not sure if it has anything to do with the save-unders (it doesn't sound like it should). The application consists of an override-redirect shell and a simple core widget. I set up a simple translation table that traps keypress, mouse, expose, and visibility events. that's just about it. dan ----------------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com 632 Petaluma Ave, Sebastopol, CA 95472 800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104 Opinions expressed reflect those of the author only.
rlh2@ukc.ac.uk (R.L.Hesketh) (04/13/90)
In article <134360@sun.Eng.Sun.COM> argv@sun.UUCP (Dan Heller) writes: >Now, to have my application consist entirely of a single override shell >with a plain core widget underneith it, I simply ignore the toplevel >shell returned by XtInitialize() and just use the new override shell as >my toplevel shell. You don't have to do this with R4. Why not use .. XtToolkitInitialize(); dpy = XtOpenDisplay(XtCreateApplicationContext(), NULL, "xlock", "XLock", options, XtNumber(options), &argc, argv); shell = XtVaAppCreateShell("xlock", "XLock", overrideShellWidgetClass, dpy, XtNwidth, 100, ...., NULL); ?? (I'll send you a full test program if you want). I assume the "App" part of the Xt{Va}AppCreateShell() comes from the "per display data" of the passed display pointer (?). >* There is no XtVa (varargs) version for XtAppCreateShell(). Hmm.. yes there is... XtVaAppCreateShell() in Xt/VarCreate.c >* There doesn't seem to be any way to specify shell-specific > resources via XtInitialize(). Yes, you can use the "options" > parameter, but this isn't quite the same thing as the Arg lists > used in the other XtCreateWidget-style calls. Why not have the > "args" and "nargs" parameters to XtInitialize (et al.) routines? If you decide to do things this way then why not use Xt{Va}AppInitialize() ? XtInitialize() is old hat 8-). Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 3682/7620