Bug 89023 - Fast user switching feature
Summary: Fast user switching feature
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdm
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist with 64 votes (vote)
Target Milestone: ---
Assignee: kdm bugs tracker
URL:
Keywords:
: 134807 135879 217738 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-09-07 19:32 UTC by danalien
Modified: 2018-04-16 20:21 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description danalien 2004-09-07 19:32:03 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    Unlisted Binary Package
Compiler:          gcc 3.4.1 Configured with: ../gcc-3.4.1/configure --prefix=/usr --enable-shared --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit
OS:                Linux

Hi, 

I would like to request a wish, a streamlined Apple-like 'fast user switching' feature (for KDE 4? ... or might one dream of anytime sooner??? *:)*)


DISCLAIMER: 'User Switching' has been part of X/{KDE,GNOME,<whateva>} since I can't recall ... it just hasn't been quite that 'mom' friendly.


Basic Idea, look at ref.00


* Individual security {
  
It is possible to start a separate Xsession (from the background); one could 'su' (or why not 'kdesu') into ${switch_to_user} and start a new 'Xsession & startkde' on the next available display and usually it switches to the new (X)session; for another user (in a secure manner), without having to go thru KDM.

      /* Note: Check 'Xservers'-file, to have (a few) 'local reserve'' defined.
          'from the background' - yes, I'm not explaining how... it's neither the place or time *shelf it, please*
      */      
}

* On the '<insert choice here>' menu/place {

Where, <insert choice here> = {Kmenu, Panel menu (kicker), an applet so one could add it to ones apple-like-menu, XOR why not somewhere else? like provide a CLI command to use?...}

     /* let's not limit from where users can access this - but make it easy to access via some API *andwhatnot* ... */

instead of only the 'Start New Session' in the Kmenu     /* which starts KDM on the next available display... blah blah */

Look at ref.01's

One should also be able to switch back and forth between the users via the menu/place ...

Look at ref.02    [use Konqueror (3.3.*?) + latest kmplayer (choose to use mplayer), and you ought to see something :)]


}

* Managing accounts {

Kcontrol center allready has under 'System Administration-->Login Manager -- [Users]', which could be used to specify whom would be visible in the 'fast user switiching'-menu.

But one ought to also be able to manually enter a user (not shown, or otherwise) - so one textbox ought to be visible in addition to the shown user(s).

}

* Because OpenGL can and XOrg can't  {

Yet, anyway *atpresentdate*

Fancy (user) switching ought to be 'shelfed' for a later time. 

It's not like 'fancy (user) switching' is at the core of the feature ... and one has to think of whom ones users are and what equipment they are running. And provide features they'll be capable of running.

}

* Of course .. {

There are other features to discuss to add/implement..etc... but this is neither the time or place!  *shelf it, please*

}

* Lastly {

Vote, show this wish to someone else you know would be interested; XOR do whateva' :)

}

- - -
ref 00 : http://www.apple.com/macosx/features/fastuserswitching/
ref 01 : http://images.apple.com/macosx/images/indexcallouts10082003.jpg
ref 01 : http://images.apple.com/macosx/features/fastuserswitching/images/fastusermenu10082003.jpg
ref 02 : http://www.apple.com/macosx/features/fastuserswitching/fustheater.html
Comment 1 Oswald Buddenhagen 2004-09-08 23:33:10 UTC
things are mostly implemented now.
not everything is apple-like, particularly the menus don't contain users that are not logged in yet; you just start a new session as before. maybe some day ...
the kdm dependency is not going to go away.


*** This bug has been marked as a duplicate of 25304 ***
Comment 2 danalien 2004-09-09 11:58:28 UTC
Sorry, but this isn't *IMHO* a 'Duplicate' of the bug you point to!

>things are mostly implemented now

EXACTLY, most of what is required is allready implemented, all that's needed is a few lines of KDE/QT code ... to add the additional functionality I'm requesting.

> particularly the menus don't contain users that are not logged in yet;
> you just start a new session as before

and what I'm requesting is much more then the simple 'Start New Session...' from the Kmenu, too.

> the kdm dependency is not going to go away

if not, it could transform, itself :), into <something else>
Comment 3 danalien 2005-03-02 13:35:43 UTC
Oswald,

Under 'KDM' [1], I read:

``Proper session-on-demand implementation including fast user switching. Oswald Buddenhagen <ossi@kde.org>"

And I was wondering if you've gone and implemented *this, Fast user switching (feature); or some other (type, way...)?


PS. haven't tried 3.4-Rc1 yet...,
---
1 - http://developer.kde.org/development-versions/kde-3.4-features.html
Comment 4 Oswald Buddenhagen 2005-03-02 13:47:20 UTC
of course not, otherwise this bug would be closed already.
Comment 5 danalien 2005-03-03 03:30:54 UTC
Oswald,

I was uncertain, and checked :)


I've also had time to test (3.4) RC1 [with klax..], and from the looks of it, 'its all there' (technically) *more then less*, all that's missing is some eye-candy GUI.

could you point me to some API docs? ... to utilize the functions you've implemented/or use (check 'whois logged in', change to VT/Xsession X, start new Xsession)
Comment 6 Oswald Buddenhagen 2005-03-03 20:21:45 UTC
the stuff is in kdebase:
kdmlib/dmctl.*
used in:
kicker/ui/k_mnu.cpp
kdesktop/krootwm.cc
kdesktop/lock/lockprocess.cc
look out for \<DM\>.
anyway, i think this desktop integration is sort of a dead end. one won't get something as smooth as on winxp/osx that way.

the answer is integrating kdm with kdesktop_lock. technically it is only a minor challenge, i think. however, to reach acceptable response times, it would be necessary to keep the greeter loaded all time. for kde sessions this is probably not as much of a concern ... unlike for non-kde sessions.

btw, what are the shortcuts for activating the user switching on those other oses?
Comment 7 danalien 2005-03-04 10:32:14 UTC
Oswald,

thnx.

> anyway, i think this desktop integration is sort of a dead end. one won't get
> something as smooth as on winxp/osx that way. 

yeah, but those OS's are ment (req.!) 'm0nst3r' PC's ... if one would compare to
cars, *they would be cars like BMW's/Mercedes-Benz's/Ferrari's.. etc.  While *we
would be the Toyota's :-)   ... so 'smooth' ain't feasible, if the hardware can't
back it up/support it :)

And it wasn't either my intention of it being 'smooth'. But more for us to have a 'fast user switich' function, ... well, a little better/improved design then what
we've had ages ago (heck, if we count CTRL+ALT+F[n]-keys, we've had 'fast user
switch' long before *they ever thought of it, and they are copy-cat'n us =)).

>  ... to reach acceptable response times, it would be necessary to keep the
> greeter loaded all time. for kde sessions this is probably not as much of a
> concern ... unlike for non-kde sessions.

um, but that'd be loading the 'hardware'.  I think memory should be reserved (as
much as possible) for active running apps (for the current user). If it takes a
short time to 'switch users' about, its acceptable.

tricks around it, would be to put the most common and used 'stuff' on the
outer-track [possible biggest diameter] on the HDD (from its (the needle's) resting
place to outest-track is the shortest it has to travel && not to mention it can read
more bits/revolution...)

another one, could be to save the most common and used 'stuff' an a speedy
flash-disk (I'm thinking Disk-on-chip's here :) *lucky b4st4rd here has 3 of such*)
and access time will be something of the past :)

> btw, what are the shortcuts for activating the user switching on those 
> other oses? 

CTRL+ALT+F[n]-keys?  =)

joke aside; don't know, I'm don't run any of those OS's :)

Comment 8 Oswald Buddenhagen 2007-04-11 14:33:33 UTC
*** Bug 134807 has been marked as a duplicate of this bug. ***
Comment 9 Oswald Buddenhagen 2007-04-11 16:39:35 UTC
*** Bug 135879 has been marked as a duplicate of this bug. ***
Comment 10 Maciej Pilichowski 2007-04-11 19:30:35 UTC
Here is my report:
--
I have recently found that I could assign keyboard shortcut for "start new session" dialog and this works great. However -- I use 1400x1050 resolution and this dialogs is sooooo tiny. Please add settings to allow the user to set the dialog size (or rather font size) for this dialog -- I would like to set it so I get 1/4 of the screen to see it from the distance. 
 
And Oswald comment:
--
the problem is that this is no dialog but a menu - so all your menus are that tiny. 
Comment 11 Oswald Buddenhagen 2012-02-25 20:17:52 UTC
*** Bug 217738 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2018-04-16 20:21:01 UTC
KDM is unmaintained and not used in KDE Plasma 5.

SDDM is the login manager used in KDE Plasma 5. If you still have this same issue with SDDM, please file an issue on the SDDM bugtracker (after doing a search for existing issues first!): https://github.com/sddm/sddm/issues/