! to the table of contents
< to the previous section:
> to the next section:
There are some for loginwindow:
[Jess Anderson writes:]
Here, I hope, is the quasi-definitive story on dwrites that affect the loginwindow. I'm indebted to several people, notably Art Isbell, Kristian Koehntopp, Dan Danz, Louie Mamakos, John Kheit, Felix Lugo, and Paul Sears, for some of the information presented here.
Remember that dwrites are not supported by NeXT; they may change with any subsequent system release. These I've checked out using 3.0; some or all may work with earlier releases, but I can't vouch for most of them.
All these dwrites must be done as root. You can also run as root and use DefaultMgr to set them (which is a whole lot more convenient if you're intending to fiddle with some of them).
After setting the things you want, restart the WindowServer by logging
out of the current session and typing exit
OK, here's what we know (or think we do :-):
Most new machines have
The font, size, color, and position of the printed string are not accessible (drat!).
This uses the tiff image pointed to instead of the standard one
(in /usr/lib/NextStep/loginwindow.app/English.lproj/nextlogin.tiff,
No relation to the dim time set by Preferences. The units are odd, I think. Felix reported them as 1/34 second. However, when I changed it to 1020, I got 15 seconds to dimming, and 680 gives 10 seconds, that I'm sure of. So I think the units are 1/68 second. Maybe Felix just thought it was too damn long! We all know it seems longer when you're not having fun waiting. :-) Whatever, the login screen dims to about half after this length of time.
This causes the panel to move around approximately in Backspace bouncing-off-the-walls-tiff fashion. The point is to avoid burning the screen phosphors, as a static image would tend to do. The animation is controlled by the next couple dwrites.
The units are seconds. The panel starts moving (assuming the preceding is set to YES) after this time. If you set it to be less than the TimeToDim time, the movement starts before the dimming occurs. I did not try zero. I can't stand waiting around for things to happen, so I use 10 seconds for both times. The default appears to be 5 minutes.
No movement occurs if this is set to 1. But it looks like the units might be approximately pixels for each change of position (the frequency of which is controlled by the next dwrite). If you put a big number here, say 200, the image moves in big jumps, but I don't know if the 200 is divided up somehow between change in x- and y-coordinates. I wouldn't worry about it much, just set it to something you like. Since my image contains readable text, I want it to scroll smoothly around, so I use the apparently minimum value, 2. The default appears to be 10.
The units are seconds. The image jumps by the amount above every this many seconds. The default is 0.0666 seconds. Bigger numbers mean slower motion. Since I don't like things being too jumpy or zooming around, I set this to 0.1 seconds. This makes my image ooze at a pace befitting an elderly person like me.
This makes it a little harder to turn the machine off; you
have to use the monitor or the minimonitor
(
Pointers to the login and logout hooks, if used. It should be pointed out that some of these things (login/logout hooks, for example) are maybe more logically set where the loginwindow is invoked by the WindowServer, namely /etc/ttys.
There are yet others. Here's the full list (thanks, Art):
[Christopher J. Kane kane@cs.purdue.edu]
Under NeXTSTEP 3.1, the login window has two buttons labeled "Reboot" and "Power" that allow a user to reboot and power down from the login window. In a public lab, this feature may be undesirable. The PowerOffDisabled default can be used to disable the buttons, but they are still shown in the window and push in when clicked (a bad user interface decision, IMHO).
The program below patches loginwindow to eradicate the restart and power buttons. It makes the loginwindow's LoginButton class instance method initWithImage:altImage:andString: a no-op (just return nil). This patch has been applied to the machines in the NeXT lab at Purdue (like sonata.cc.purdue.edu for instance), and no adverse effects have been noted.
This program must be run as root, since it writes to the file /usr/lib/NextStep/loginwindow.app/loginwindow.
An archive with a compiled executable has been submitted to sonata.cc.purdue.edu.
FAQ-Authors note: We strongly recommend to do a backup of the loginwindow application, because the patch alters the file directly and will most likely not work on different versions of the OS.