24 Apr
2012
24 Apr
'12
12:34 p.m.
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