[RFC+PATCH] xp-like fast switching

[Oswald Buddenhagen]

well, to be honest, i don't know exactly what m$ did. i've seen only
part of it and this was quite some time ago. the rest is from user
reports.

On Tue, Sep 24, 2002 at 10:44:08AM -0400, Ian Reinhart Geiser wrote:
> 	User A logs in... opens apps and "closes" their session.  *Note
> 	everything is all running still, but they dont know that User B
> 	login in and starts even more apps then "closes" their
> 	session...
> 
there will be no "close" action, only the normal "lock" one. everybody
openinig a new session will do so either directly from an "open" session
(scenario "husband lets wife check her mail") or from a (visibly) locked
session (scenario "a went to lunch and b takes the opportunity to
<whatever>"). there is simply no "does not know" scenario, at worst "has
forgotten" (but the first user will certainly remind him ...).

> Senario b) (yes, i actualy got this call from a user)
> 	User A logs in, starts to work on a report... its lunch so he ducks out
> 	User B comes along and wants to check his email... for some reason
> 	his email wont work (probibly because the other accont had AOL open at
> 	the time) 
>
you must admit that this particular aol scenario is unprobable on *nix. :)
in general such locking problems should never occur.

> so they do the magic reboot...  
> 
> 	Result... User A loses his unsaved changes... 
> 
- again that only can happen if b does not know that a is there (or b is
  a irrespective asshole).
- you can instruct kdm to refuse reboot when sessions are active. that
  will be extended to be interactive, so the user actually is informed
  why the reboot failed ...
- you can instruct kdm to refuse reboot at all ... (and you can un-wire
  the reset-/power-buttons of the machine :).

> In short this is a dangerious feature that users will abuse and use to
> break their KDE in new and entertaining ways.
>
sure they will ... but (almost) every feature can be abused.

> Lets refrain from copying every feature our great MS tells us to
> implement and maby come up with our own, better way of doing things.
> 
as a die-hard m$-hater i take offense on this statement. ;)
no, seriously, i'm implementing this, because i received quite a lot of
requests to do it and many of them were backed by sensible use cases. an
idea isn't necessarily bad because m$ implemented it first (and badly)
or because there is other bad software around that does not play along 
well in multi-user environments.

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Ceterum censeo M$ esse delendam.