I am bumping this report from enhancement request to bug report to address some TSAK and desktop locking bugs. Several related bug reports already exist but these specific issues should remain separate so as not to clutter the other bug reports and get lost in the shuffle.

Screen saver activation should be part of the locking process, whether initiated through TSAK or the Lock applet. All dialogs appear before the screen saver. This is the opposite behavior of KDE3 and other desktops. This new behavior is not good or bad but will require long-time users time to grow accustomed.

A good compromise is when the appropriate action is taken with each of the respective dialogs, the screen saver then immediately activates.

When the Secure Desktop Area dialog appears, and after selecting the Lock Session button, the mouse pointer turns to an hour glass. Many users will find that behavior confusing. The "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 happens and the mouse pointer remains in this busy state until the user bumps the mouse or presses a keyboard key. The busy pointer doesn't feel or look right. 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 functions in most other desktops.

(In reply to comment #1)
> I am bumping this report from enhancement request to bug report to address some
> TSAK and desktop locking bugs. Several related bug reports already exist but
> these specific issues should remain separate so as not to clutter the other bug
> reports and get lost in the shuffle.
> 
> Screen saver activation should be part of the locking process, whether
> initiated through TSAK or the Lock applet. All dialogs appear before the screen
> saver. This is the opposite behavior of KDE3 and other desktops. This new
> behavior is not good or bad but will require long-time users time to grow
> accustomed.
You can grow accustomed used to it if you want.
I tried to grow accustomed to KDE4 and now I use Trinity.
> 
> A good compromise is when the appropriate action is taken with each of the
> respective dialogs, the screen saver then immediately activates.
Compromise implies a lack of choice. Why not provide a choice?
> 
> When the Secure Desktop Area dialog appears, and after selecting the Lock
> Session button, the mouse pointer turns to an hour glass. Many users will find
> that behavior confusing. The "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 happens and the mouse pointer
> remains in this busy state until the user bumps the mouse or presses a keyboard
> key. The busy pointer doesn't feel or look right. 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 functions in most other desktops.

I'd like to be able to choose "classic KDE behavior".
Provide all the alternatives you like, but please allow me to choose the one I'm used to or the one I like the best, just like the start menu.

Is this something Trinity is unwilling to compromise on, given the reason for its inception?

> Is this something Trinity is unwilling to compromise on, given the reason for
> its inception?

Actually, you can get the old behaviour back right now if you want. :-)

There are several configuration options in kdesktoprc: UseUnmanagedLockWindows, UseTDESAK, and DelaySaverStart.  Set them as follows to restore the old behaviour:

UseUnmanagedLockWindows=true
UseTDESAK=false
DelaySaverStart=false

I thought that I had provided a GUI checkbox in the kdesktop config module to set the old behaviour via these options, but it is very possible that I never got around to implementing it.

That explains why I never found the GUI options. :-)

1. How is UseTDESAK different from useSAK in tdmrc?

2. Where in KControl should the GUI controls for these three options go?

3. Considering my comments, would adding the GUI controls resolve this bug report?

(In reply to comment #4)
> That explains why I never found the GUI options. :-)
> 
> 1. How is UseTDESAK different from useSAK in tdmrc?

It is a secondary override of useSAK; a user can decide to disable the SAK dialog if they don't want to use it.  Probably a stupid idea from a security perspective and I am likely going to remove it entirely (it was left over from the very beginning of the SAK implementation, before tdm was integrated into the SAK system).

> 2. Where in KControl should the GUI controls for these three options go?

The most logical place would be the screen saver configuration page of the Background configuration module.

> 3. Considering my comments, would adding the GUI controls resolve this bug
> report?

I think so.

Okeydokey.

Note:

I looked at tdebase/kdesktop/lock/main.cc. The underlying support for those three options is not yet implemented. The three keys have been defined/added to tdebase/kdesktop/kdesktop.kcfg (no What This help yet), but I don't see anything in the code that reads the keys --- only a traditional FIXME. Looks like the three options are hard-coded to false.

Thus manually editing kdesktoprc is not yet possible, which would be nice to provide an interim work-around.

There is a fourth kdesktoprc key defined in kdesktop.kcfg: ShowLockDateTime.

Perhaps if you provided the What This help snippets for those four keys, which would provide a basic understanding of their intent, then somebody could start on the readEntry and writeEntry snippets in main.cc.

I revised the bug report summary to reflect that these GUI controls are missing. This way we now have a tracking mechanism whereas the FIXME deep in code is easily forgotten. :-)

(In reply to comment #6)
> Okeydokey.
> 
> Note:
> 
> I looked at tdebase/kdesktop/lock/main.cc. The underlying support for those
> three options is not yet implemented. The three keys have been defined/added to
> tdebase/kdesktop/kdesktop.kcfg (no What This help yet), but I don't see
> anything in the code that reads the keys --- only a traditional FIXME. Looks
> like the three options are hard-coded to false.

No.  Look for these lines:
        trinity_desktop_lock_use_system_modal_dialogs = !KDesktopSettings::useUnmanagedLockWindows();
        trinity_desktop_lock_delay_screensaver_start = KDesktopSettings::delaySaverStart();
        trinity_desktop_lock_use_sak = KDesktopSettings::useTDESAK();

The options are quite active!

> Thus manually editing kdesktoprc is not yet possible, which would be nice to
> provide an interim work-around.

Actually it is possible.

> There is a fourth kdesktoprc key defined in kdesktop.kcfg: ShowLockDateTime.

That does exactly what it sounds like--shows the date and time of last lock engage on the unlock screen for intrusion detection purposes.

> Perhaps if you provided the What This help snippets for those four keys, which
> would provide a basic understanding of their intent, then somebody could start
> on the readEntry and writeEntry snippets in main.cc.

useUnmanagedLockWindows: When TRUE, this restores the "original" unmanaged window behavior of kdesktop_lock.  See the X11 docs for the meaning of "unmanaged". ;-)

delaySaverStart: When FALSE, the screensaver starts up immediately on lock engage.

useTDESAK: Probably going to be removed.

> I revised the bug report summary to reflect that these GUI controls are
> missing. This way we now have a tracking mechanism whereas the FIXME deep in
> code is easily forgotten. :-)

Great!

Ah, you went and changed case on me.... :-)

A quick glimpse at the sources indicate the underlying support was added after the official 3.5.13 release.

Okay, I'll push the What This help to GIT, although there are no GUI controls yet to read them. At least they will be there.

I'll test the options with manual editing and report how that goes.

(In reply to comment #8)
> Ah, you went and changed case on me.... :-)
> 
> A quick glimpse at the sources indicate the underlying support was added after
> the official 3.5.13 release.

Sorry about that.  The lock process is actually somewhat of a mess on 3.5.13, and I don't know how much of the current version can be safely backported due to its new interface to kdesktop.

I did not mean to sound like I was pointing fingers. I only meant that if people are using 3.5.13 then they will have a challenging time trying to help test the options through manual editing. :-)

I looked at the effected files in the GIT repository history. Backporting a set of patches is doable, but is palatable only to those who don't mind compiling.

We'll get there one way or another. :-)

(In reply to comment #10)
> I did not mean to sound like I was pointing fingers.

You didn't.

> I only meant that if
> people are using 3.5.13 then they will have a challenging time trying to help
> test the options through manual editing. :-)

Of course. :-)

Tim

I tested the aforementioned three kdesktoprc keys:

[ScreenSaver]
DelaySaverStart
ShowLockDateTime
UseUnmanagedLockWindows

All three options seem to work as intended. I tested them in various combinations, both with command line login and graphical login (TDM). With the latter I tested with useSAK=true and useSAK=false.

DelaySaverStart=false starts the screen saver immediately with any locking action. For now the workaround is to edit kdesktoprc, but the old behavior is possible.

Likewise, the older simplified dialog for unlocking the desktop is available with UseUnmanagedLockWindows=true.

The ShowLockDateTime key has no effect when UseUnmanagedLockWindows=true (using the older simplified dialog).

One quirk is with DelaySaverStart=false the screen saver starts even when the user has the screen saver disabled (Enabled=false). Bug or feature?

When useSAK=false, DelaySaverStart=true and Enabled=false, no screen saver appears at all. This behavior matches the logic, but I wondered about how this combination might affect monitors powered on 24/7. Users could lock the screen at the end of the day and the dialog would burn in at the spot all night. Repeated nightly and some monitors would suffer from image burn-in problems. Presumably few non DPMS monitors remain in service these days, but their usage should not be ignored. On the other hand, to forcibly activate a screen saver probably means using the default blank screen, which could startle some users. An alternative would be to use the random screen saver. Regardless, I hate "corner case" discussions. :-)

Twice when I had DelaySaverStart=true the screen saver started immediately, but no dialog appeared when I pressed a keyboard key or moved the mouse. I was testing in a VM and I won't claim a bug in Trinity because I have seen oddball video behaviors with VMs. I mention the quirk here for the record in case others report a similar behavior.

The busy cursor issue is gone, resolved through the patch in GIT hash 4d538e40. The busy cursor still exists with the Secure Desktop Area dialog.

Note: To whomever adds the GUI controls for these three options. One of our project goals is to eliminate any configuration dialogs accessed through an "Advanced" button. The top level screen saver dialog is an example. When adding the GUI controls for these three options, would be nice if at the same time the dialog from the Advanced dialog was moved to the parent dialog and the Advanced button removed.

Seems all we need to close this bug report are three check boxes. :-)

Re: TRINITY DESKTOP ENVIRONMENT 3.5.13.1 SRU RELEASED

Great stuff!

I had to downgrade for a bit to 3.5.12, which does/did everything the way I like it, using xfce or lxde wireless but one can't live in the past...

I just tried those flags again:
[ScreenSaver]
DelaySaverStart=true # So the screen saver can grab the desktop image
UseTDESAK=false
UseUnmanagedLockWindows=true

but when I lock the screen it goes black, so the science screensaver may be running - but if it is then it's a black cat in a coal bunker.

Pressing any key brings up the (classic) unlock dialog.

Locking the screen again logs me out.

Still no checkboxes to manage these in systemsettings.

(In reply to comment #13)
> Locking the screen again logs me out.

That's not good, it sounds like the lock process might be crashing.  In all honesty the classic lock dialogs are not receiving much testing in the field at this point, however I still want to see these problems fixed.

> Still no checkboxes to manage these in systemsettings.

Raising priority so that this (hopefully simple) feature request makes it into R14.

Where is the appropriate location these three check boxes should be placed? Screen Saver?

I'm undecided between "Appearance->style" "Window behavior" "Login Manager" and "Desktop->Screen Saver".

I'm guessing users will look in those places too, but not necessarily in the above order.

Just now I found a way to temporarily disable a "Window Behavior/Window Specific Settings" entry for testing - put an "X" in the name and at the end of the window role.

I've always wondered why I couldn't alt-tab to Synaptics dialog boxes.

It just goes to show that users can miss settings even when you put them in a logical place.

Maybe there should be a global config editor where users can search for a setting, like with "Icedove->Preferences->Advanced->Config Editor".

My 2c.

The classic screensavers have been repaired in GIT hashes 2771be6 and 4120a76.  

There is now another settings key that you may want to change to get the old insecure behaviour back, so the full list of keys that must be set for a complete reversion is:

DelaySaverStart=false
UseTDESAK=false
UseUnmanagedLockWindows=true
HideActiveWindowsFromSaver=false

HideActiveWindowsFromSaver prevents the screensaver from grabbing a snapshot of your active workspace when set to true (the default).

(In reply to comment #16)
> Maybe there should be a global config editor where users can search for a
> setting, like with "Icedove->Preferences->Advanced->Config Editor".
> 
> My 2c.

This is a good idea!  It could be implemented in kcontrol similarly to the Kicker search bar; i.e. show the user where to find the setting an dhow to get to it so he/she doesn't have to search for it the next time.

Tim

KControl already has a nominal search feature. Of course, only nominal and only related to KControl.

GUI controls added to the screen saver module in GIT hash 02d43b7.

Thanks for reporting!

Created attachment 1131 [details]
Fix use useTDESAK in kdesktop_lock

I tested new checkbox Use Secure Attention Key, and I found that the value useTDESAK is indeed set, but not used anywhere.

Proposed patch attached.

(In reply to comment #21)
> Created attachment 1131 [details]
> Fix use useTDESAK in kdesktop_lock
> 
> I tested new checkbox Use Secure Attention Key, and I found that the value
> useTDESAK is indeed set, but not used anywhere.
> 
> Proposed patch attached.

That patch will have a couple issues; let me work on an update and get back to you.

Thanks for catching this!

The new setting has been activated in GIT hash 091b1ef.

Thanks for reporting!