> Some additional information: one symptom of this problem is > kdesktop_lock not exiting properly and going zombie, e.g. > ps aux | grep kdesktop_lock shows something like > user <pid> 1.1 0.0 0 0 ? > Z 14:45 0:00 > [kdesktop_lock] <defunct> > > This indicates a problem in kdesktop itself. I tested again with the latest patch for a race condition. The patch has stabilized just about everything. :) No more desktop icon disappearance. The desktop context menu works. Alt-F2 works. I can logout using any option. No misbehavior when selecting the Task Manager or Cancel buttons. Comments: * I still notice the tsak Ctrl-Alt-Delete dialog appearing momentarily before the Desktop Session Locked dialog appears. I think a slower system is needed to see this, like a VM, because I can't see the dialog when running on my regular hardware. I doubt the dialog appearing is good or intentional. Especially when I see the dialog in command line login mode, which means tsak is not supposed to be in the picture at all. Not to mention that appearing momentarily like that does not look "high quality." :) * All dialogs appear before the screen saver. I don't know that this is incorrect or bad, but is the opposite behavior of KDE3 and will require long-time users time to grow accustomed. * For years I have used Ctrl-Alt-Delete as my logout shortcut. That shortcut works except when useSAK=true. The missing element is the Logout button is ghosted/disabled in the dialog. You mentioned that the feature has not been implemented, but seeing that feature added will be nice. :) * As mentioned previously, the Secure Desktop Area dialog does not show root's account name in the dialog. Just the single quotation marks with nothing in between. * When the Secure Desktop Area dialog appears, and after selecting the Lock Session button, the mouse pointer turns to an hour glass. I think many users will find that confusing. That "busy" mouse pointer indicates something is going to happen, that the system is busy doing something. The inclination for the user is to wait for the "busy" condition to dissipate because that is what users are accustomed to doing. Yet nothing ever happens until the user bumps the mouse or presses a keyboard key. The busy pointer doesn't feel right. Perhaps instead of the busy pointer, the screen saver should activate immediately. Immediately activating the screen saver also provides feedback that the system is locked because that is how the process functioned in KDE3 and other desktops. * I have not yet seen the CPU hogging issue return but others who witnessed that mystery will have to test further. I saw that happen only once. Good job with the patch! Darrell