[RFC+PATCH] xp-like fast switching

Ian Reinhart Geiser geiseri at yahoo.com
Tue Sep 24 17:30:58 BST 2002

Hash: SHA1

On Tuesday 24 September 2002 11:22 am, Oswald Buddenhagen wrote:
> 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.
well if users want to use XP, then they should? right? ;) 

> 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 ...).
Okay, that is much better, the current XP implementation confuses the idea of 
logging out with locking the session.  This is annoying because even as a 
user who knows what the hell is going on, its easy to get confused.

> > 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.
No, but there are conditions of hardware getting locked by one user, say a 
modem or soundcard.  Have we tried to run multiple artsd instances yet... 

> > 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).
most end users have been trained my ms to "if in doubt reboot"...

> - 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 ...
I like this idea in general...

> - you can instruct kdm to refuse reboot at all ... (and you can un-wire
>   the reset-/power-buttons of the machine :).
if i had my way users would all be using dumbterminals anyway ;)

> > 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.

this is not directed at you but at KDE in general.  Im not a MS hater, but I 
am also not an MS lover...  I just find it offensive that we strive to copy 
MS at everything they do, and then push it off on the users, saying they 
wanted it.  I dont mind some compatability of metaphores, and some migration 
tools, but I think we need to evalutate features and their conciquences.  (i 
say this as my cdrom icons dance to random places on my screen because of a 
poorly researched copy of a MS feature that even MS is trying to get away 

I think you should spend an afternoon playing with this feature on XP before 
you try to copy it.  There are many nuances that are missed by screenshots 
and press releases.  Even by users, since they dont have the eye for design 
that you have as the person implementing the feature.  Im not saying that 
yoru implementation will be bad, im just saying dont copy XP from the screen 

- -ian reinhart geiser

- -- 
Excess on occasion is exhilarating.  It prevents moderation from
acquiring the deadening effect of a habit.
		-- W. Somerset Maugham
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list