Version: (using KDE KDE 3.5.1) Installed from: Gentoo Packages OS: Linux Hello, after an upgrade to KDE 3.5.1, I have experienced one nasty thing - when I want to switch to another session, I find that the screen is _always_ locked and I need to type in the password ... This did not happen with the previous version (3.4.3) and I have not found any configuration option for this in kcontrolcenter (and after some Googling, I think I am really not alone so this is not only my blindness ...) This may be related to bug #118348, but it happens even for session with screensaver disabled (while I made sure that it is NOT set to ask password for any of the users' accounts ...) Btw, I cannot tell if the screensaver gets activated somehow because the screen is always messed up after switch (while the password dialog displays ok) and it gets right only after unlocking the session.
this is intentional. the reasoning is, that for really fast switching without locking you can use alt-ctrl-f<n>. not sure how to do it better: - put a check box in the "switch user" menu. this is *very* uncomfortable for people who often need both modes (just experimenting with two sessions vs. actually "borrowing" the system). - replace the "lock session" K menu item with "lock and ..." with the sub-entries "just lock", "start new session" and the entries for the running session, and make the "switch user" submenu all without locking. a simple solution is automatically not locking if switching to a session owned by the same user. however, then somebody will certainly request a per-user whitelist of other "lock free" users, which wants to be configured somehow.
> for really fast switching without locking you can use alt-ctrl-f<n>. there are users who do not remember any keyboard shortcuts, especially if there is an option to do that with mouse via menu ... and, in my opinion, security of switching via keyboard shortcut should be consistent with switching via menu (but I am not sure if this may be done in KDE, aren't the ctrl+alt+fN combinations handled by X itself?) > - replace the "lock session" K menu item with "lock and ..." with the sub-entries "just lock", "start new session" and the entries for the running session, and make the "switch user" submenu all without locking. to me, this looks comfortable enough - the "clicking effort" is the same, you just select another menu item ... of course this affects people who use "just lock" often but I would bet they prefer "logoff/lock" applet instead of the menu anyway ... I think that to implement the switching this way would be fine, but if you want to discuss another solutions (switching without explicitly selecting whether to lock) - > a simple solution is automatically not locking if switching to a session owned by the same user. well, IMHO this is reasonable default which should be implemented regardless of the solution with another users (but please, make this configurable ... this is one of the things about KDE that I like best, that a lot of behaviour can be changed with little effort) > however, then somebody will certainly request a per-user whitelist of other "lock free" users, which wants to be configured somehow. yes, this would certainly be a nice thing too :-) but I would start with the other way round - to allow user to configure if he wants to lock when switching to another session (regardless of the target)
Hi Kavol, why do you switch between sessions at all? For what usages do you (and the others you found via Google) need this? BTW, you could try to use http://www.kde-look.org/content/show.php?content=26150 which let's you adjust the locking behaviour on the fly :)
> why do you switch between sessions at all? because it is much more comfortable then to log-out/log-in each time when switching users > For what usages do you (and the others you found via Google) need this? go ahead and ask them ... or, alternatively, you may ask people behind KDE or from Microsoft why do they implement such features > BTW, you could try to use http://www.kde-look.org/content/show.php?content=26150 which let's you adjust the locking behaviour on the fly :) (the screenshots) look like this does exactly the same as the current session switcher plus the feature mentioned in comment #1 as "very uncomfortable" ... however: Sessionapplet $ ./configure --without-arts [... a lot of messages ...] Good - your configure finished. Start make now Sessionapplet $ make WARNING: use unsermake instead of make or use a wrapper script, e.g. makeobj!!! unsermake all make: unsermake: Command not found make: *** [all] Error 127 # emerge -av unsermake These are the packages that I would merge, in order: Calculating dependencies !!! All ebuilds that could satisfy "unsermake" have been masked. ... so, you want me to install some unstable tool just to try some alpha version applet which is not-quite the thing I would like to see in KDE? - no, thanks, I'd rather keep my system going ... maybe when I have more time ... but still, although some users may find this useful, I do not see this applet as a solution (btw, does the setting in the applet affect switching via system menu? - maybe a silly question, but I do not see inside, what is called from where etc.) btw, "Description: A small applet, done as proof of concept for KDE 3.5, but not ready in time for the feature freeze. So hopefully it will make it's premiere with 4.0. Already works like a charm, but does not cooperate too much with the other session controls right now. Should be stable but is alpha code featurewise. Still it is usable on its own. Please try it and comment on it." - really very descriptive description ... not a single occurence of the word "switching" (or "switch") which is the thing it deals with (and what I was looking for) p.s. sorry for being a bit offtopic
> > why do you switch between sessions at all? > because it is much more comfortable then to log-out/log-in each time when switching users Sorry, I meant, why do you need to switch users at all? And why is locking a problem? Are you developing and testing different setups which cannot be tested with e.g. XNest? And/Or is your local display only accessable by you and does not need any authentification? Or what are you doing? > > For what usages do you (and the others you found via Google) need this? > go ahead and ask them ... or, alternatively, you may ask people behind KDE or from Microsoft why do they implement such features It is much more interesting what users are doing with these features finally ;) It may not be what the implementer imagined. Collecting use cases from users helps to improve the software to solve the real problems :) Yes, the checkbox is uncomfortable (because I did not implement something to prevent the menu to close on click there, though perhaps possible). But (for me) it is an improvement about what is available with pure KDE now :) And thanks for the eye-opening comment on the applet. You are right, I should improve the description and switch off unsermake. Will do so next week, as I have a slightly improved version sitting on my hard disk for a while anyway. So if you still want to try it, please visit the url around next weekend :) And no, the setting does sadly not affect the switching via system menu, as it talks with kdm on it's own, it being an isolated prototype. :/ Well, I simply ignore the system menu since then. :P Okay, not good with end users. Well, it's a prototype. On your opening comment, Kavol: I think synching the default behaviour with the screensaver makes a lot of sense (need for local reauthentification). If one really needs/wants to lock her session she still can do it by locking it and then switching in the screensaver dialog. Well, the other way around (notlocking switching by menu when there is a locking screensaver) may call for more problems then wanted, so I would vote to be lazy with support for it (Experts may still use the shortcut workaround). What do you think, Oswald?
> Sorry, I meant, why do you need to switch users at all? the first scenario - my notebook: I am doing all my work on it, usually I keep open things which do not restore as a part of session and it is not desirable to terminate them (e.g. compiling something on remote machine when it takes long and I have not run it with nohup) I have to take a rest and my girlfriend comes to ask "may I have a look at ..." so I just start a new session where she logs in and does her work; then when the rest is over, I can return to my session exactly as I left it despite the other bonuses of user separation, I do not want her to mess with my session anyway - she is (was?) a typical Windows user and there is a lot of problems which can be prevented this way (e.g. she could not understand when I was angry because she "just closed browser" - she did not know anything about tabbed browsing and that by closing window with more tabs she destroyed more than two hours of my work - going through Google results and picking up the relevant ones) the second scenario - computer at my parents': I use this computer as a datastore, so it runs non-stop ... and since it runs non-stop, I do not feel the necessity to log-off - I like to keep running things like ktorrent (ok, there are BT clients that do not require X, but I really like this one ...) so, my parents have to run another sessions ... and they run it in parallel, because, as said before, it is much more comfortable to switch than to log-off/log-on ... which gives us an answer to: > And why is locking a problem? because it is very uncomfortable; or at least my father finds it so ... I was glad to teach them to switch user accounts and I do not want to see any obstructions for this (especially if they were not there before!) I need them to have a strong password because sometimes I need to login from a computer for which I do not have ssh keys (using "su" from my account has problems with X authentification) and typing strong password several times a hour(*) _is_ annoying (*) the real situation: father writing some long letter, mother coming every five minutes asking "does the important email arrived?", father angry enough because of the interruptions, and in addition the password has to be typed twice just to switch, see no new mail and switch back ... instead of four simple mouse clicks as it was before switching via ctrl+alt+f? is not a solution, for three reasons (partly discussed before): 1. there is no will to learn shortcuts 2. the behaviour should be consistent (imho) 3. you have to know which user has which session number (instead of seeing the name in menu) maybe there are some workarounds for the problems mentioned, but they are not obvious enough to be actually used (e.g. I have a very rough idea about what XNest is, but I know nothing about how it can be used to run multiple sessions ... it surely is not one of the things that inexperienced user gets to just after his first start of KDE ...) as for your applet - I see no new version now :-) > But (for me) it is an improvement about what is available with pure KDE now it surely is and I am glad that someone is doing something in that way, but the whole situation looks to me like a step back ... as for screensaver and locking - if I get you right (?) I agree ... but I have noticed one thing: sometimes the display is not messed and it is possible to see part of the screen of the user I am trying to switch to ... this should not happen (if a user locked his session in order to prevent others to access his data, he probably do not want them to be able to read it from screen either ...)
Hi Kavol, sorry for the delay, time got hijacked by the real life. Thanks for giving some scenarios, noted them for some later review. If you still would like to try the applet, I just uploaded a new version, now without unsermake: http://www.kde-look.org/content/show.php?content=26150 Regards Friedrich
I also dislike the unability to configure this behavior. I have a few users, where one of them must be without any password. Sure, this user got not many rights, but must be able to log in without a password. The login itself is no problem, but switching users is! I tried several things, even user profiles with "lock_screen=false" in config file. This is what this comment should tell. ;-) When a user mustn't lock the screen, configured in his profile, he can still lock the screen by switching users! The K-menu item for session lock is gone, the keyboard shortcut doesn't work but the screen gets locked when switching users. Not good, IMHO. :-(
the status change of this bug has remembered me that I wanted to try the newer version of the session applet - but the download link is broken? p.s. my parents still have not mastered ctrl+alt+fX, so they need to type password on each switch (which results in receiving e-mails from mother using father's account etc. - users' laziness is infinite :-))
Is anything being done about this. I now find with 3.5.8 that I can no longer use <Ctrl><Alt><F?> to switch desktops when I am in a KDE X session and if I switch back to a KDE X session with <Ctrl><Alt><F?> that the screen is locked. This makes it rather inconvenient when doing development work on my system. Can these 'features' be turned off PLEASE? This doesn't need to be GUI, adding to "kdeglobals".
*** Bug 185795 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > *** Bug 185795 has been marked as a duplicate of this bug. *** just a note ... the same in 4.3 RC1 ... this is still a problem
I just upgraded to Kubuntu-9.10 and user switching is still fundamentally broken. When switching between users, the only thing I get is a black screen with a frozen mouse pointer. Nothing else and no reaction to mouse movements or key presses. Sometimes the session seems to restore after around halve a minute of mouse clicking and drumming the keyboard and I get a login screen for the current session.
*** Bug 227930 has been marked as a duplicate of this bug. ***
It would be nice to have an option in KDE4 to start a new session without locking the current one. This is available in KDE3 but missing from KDE4.4.
Here is a workaround for the "lock on new session"-problem until it's fixed: http://forum.kde.org/viewtopic.php?f=66&t=10052#p75129
this logically somewhat related to bug 103046, which is very much a login manager thing. but the user switching frontend is in krunner (using libkworkspace).
While this bug per se isn't fixed, the sessions runner has been superseded by the new session switcher and I'm not going to put work into the former anymore, sorry.