Jakub: Obviously, the primary user of a user-switching tool will be the home user, but it does have some use within a small office (and perhaps in the star-trek future it has some use in a large office).
The basic use case is someone who wants to switch to their login to do something without disturbing the existing session (which may very well be left unlocked, unattended, and without saving the open work — in spite of everything we tells the users, the editor in chief left himself logged on to two different lab machines one day, and he just got his login a week ago).
But, assuming a perfect world where users didn’t turn disable screensavers and leave themselves logged in, select dictionary passwords and/or write them on sticky notes taped to lab monitors, here’s a case that has occurred before:
- Jeff works in a campus paper’s newsroom as a photo editor. There are around 80 employees, of whom 30 will be in the office at any given time. There are enough computers in the lab to go around, but only some of machines have special tools on them (like a digital camera media data-recovery tool which requires raw disk access, which the admins have restricted so only one machine can be hosed if the photo guys get their accounts stolen). Jeff (obviously) already knows his own name and face, as well as his username and password, but doesn’t really care about computers beyond them working. Further, he is working under a deadline and thus really needs to use the computer which has the recovery tools ASAP, but the machine is in use already.
This scenario illustrates (I think) that more complex environments must be taken into account even for something as trivial as FUSA, and was what I had in mind. But really, I think “make FUSA not suck with lots of users” is a laudible goal anyways. The ideas for handling that many users boil down to (essentially):
- Make FUSA into a “recently used” list, with the last 5-10 users who have logged in.
- Only show currently logged-in users.
- Show all user accounts.
#1 can only really use utmp to see who the last few users were, and I can see it getting irritating — sometimes your user shows up in the list, sometimes it doesn’t. I’d guess that people will scan the user list to find their user, and after not seeing their user a few times, will get into the habit of just going straight to the “login screen” item to save time, effectively killing the usefulness of showing the users at all. #2 is better, as the list will be smaller, but otherwise shares the same problem as #1. #3 shares one of the problems of #1 (the user must scan the list), but at least the user is gauranteed their account will be in the list — with photos and properly filled-in GECOS names, the scanning shouldn’t be that difficult providing the user is in basically the same place in the menu all the time.
So, I don’t really think #1 fits the use-case (and available user accounts is much closer to available applications than recently-used documents, IMO), and the decision of #2 vs. #3 is close enough to call (e.g. you may not want to show all the available usernames) that it should be a hidden option.
Update:Sorry, Jakub, for misspelling your name (yeah, I’m an idiot).