Summary

The FUSA applet in Jaunty is tied closely to the GDM that is shipped in Jaunty. There are several large patches that Ubuntu has shipped as distro patches to add functionality into the FUSA applet including status switching for IM applications and session management support. These functionalities must be combined with the ability to switch users on the new GDM in Karmic to ensure that users do not see a regression when using the Ubuntu Desktop in Karmic.

Release Note

Rationale

User stories

Assumptions

Design

Architecture Diagram: PNG | DOT

The design consists of making three smaller modules that implement each set of fuctionality. Mostly these smaller modules will translate them into a set of menu items that will be then communicated to the small visual element that is in the panel.

Keyboard Shortcuts

Some menu items in the applet have configurable keybindings via the gnome-keybinding-properties program. For menu entries with keybindings, the keybinding should be displayed.

Updates on Shut Down

... in progress ...

Fast User Switching

The following rules determine the user interaction for the user switching features:

System has only 1 administrator or regular desktop user:

----------
Lock Screen
Guest Session
Log Out...
----------

System has more than 1 administrator or regular desktop user, and fewer than 7 such users:

---------------
Lock Screen
Guest Session
Switch User   > | User 1
                | User 2
                | ...
                | User (n < 7)
Log Out...
---------------

System has 7 or more administrators or regular desktop users:

---------------
Lock Screen
Guest Session
Switch User...
Log Out...
---------------

Choosing "Switch User..." brings the user to the normal login screen. "Switch User..." is placed after "Guest Session" because the former is likely to be more heavily used on a system with many user accounts (e.g. home vs. university lab) and bookended menu entries are easier to locate quickly.

Further Usability and Design Decisions

Do we agree with all the items in the menu? Do any of them have a better home?

It may be a good decision to integrate "Guest Session" with the face browser to effect uniform treatment of user switching, whether the user being switched to is a first-class user or a guest user.

Eventually, "Suspend" should be renamed "Sleep." "Suspend" is a harsh word with negative connotations, while "sleep" is pleasant, personified, and complements "Hibernate." If renaming to "Sleep" is feasible for Karmic, this should be done.

When we suspend and hibernate should we dim the screen, lower the music, set IM statuses?

When the computer is put to sleep, the screen should be dimmed slowly. Any playing media applications (e.g. music, movies) should be paused. IM status should be set to "offline", but should be reset to the user's status before the computer was put to sleep.

What do all those statuses mean?

We need to explore meaningful status icons that do not depend on color. This is less important for Karmic, but over time we will need to desaturate status icons if they are displayed persistently in the panel.

What icon should be shown on the panel when an IM client is not active? Not online? Are they the same?

User status should always be one of the status options available. If the IM client is not active, the user's status should be "Offline" and the corresponding offline icon should be used.

If the lockdown setting is set to not allow locking the screensaver should the item be missing or insensitive?

If the user does not have permission to lock the screen, do not show the "Lock Screen" menu item.

If there is no display manager (LTSP, etc.) how should the display manager items be shown?

If the computer can't suspend/hibernate should those be insensitive or hidden?

If the user does not have permission to suspend or hibernate, do not show the "Suspend" or "Hibernate" menu items. I am not sure what is meant by "if the computer can't".

We can to some extent, figure out if there are applications who want to block session logout. Even if the information is unreliable, should we try and use it? (probably Karmic + 1, as we'd need time to test the reliability)

If we can determine that an application wants to block session log out, we should do our best to tell the user. NEEDS INFORMATION about the reliability mentioned.

What can the user configure in the applet settings?

...

Implementation

UI Changes

Besides small tweaks the UI will remain stable. The following mockups are not-pixel perfect, and are only demonstrations of status and user switching in submenus.

fusa_2.png fusa_3.png

Basic menu structure:

----------------
Full User Name
Set Status     >
About Me...
----------------
Lock Screen
Guest Session
Log Out...
----------------
Sleep
Hibernate
Restart...
Shut Down...
----------------

When user does not have privileges to shut down, restart, etc.:

----------------
Full User Name
Set Status     >
About Me...
----------------
Lock Screen
Guest Session
Log Out...
----------------

See Fast User Switching (above) for further details on menu structure.

Code Changes

The development will reuse the current libraries and infrastructure that was developed as part of the messaging indicator project. This includes a mechanism for loading the applet and also the dbusmenu project for passing simple menus over DBus. It will then build on these adding the specific functionality required for the functionality. Hopefully, the patches already built for FUSA can be pillaged for the majority of this functionality.

In the case of having to doing microblogging functionality or software updates on shutdown those will be integrated into the appropriate modules. This would be entirely new code.

Migration

The largest migration issue with the new applet will be handling GNOME Panel settings. Previous development on the FUSA applet used the same namespace, as it was patches to an existing applet. This made it difficult for the vanilla-GNOME effort as it was difficult to excise the new features from the applet itself. It is then desirable to use a new namespace, which leads to panel configuration issues.

Fortunately, in this case, the applets should be interchangable visually. So it is only a matter of replacing the applet's settings with a pointer to a new applet. As soon as the new applet is available this migration should be attempted to figure out any possible issues with the migration. The migration will be done with a packaging script similar to other gnome-panel settings migrations that have been done in the past.

Test/Demo Plan

Testing will occur at multiple levels using different techniques. To test the individual logic components unit tests will be written using dbus-test-runner to allow for testing them in an isolated testing environment. Further tests will be integrated into the mago project for UI testing. This also includes some IM stubs for testing networking related protocols.

Unresolved issues


CategorySpec

DesktopTeam/Specs/KarmicFusa (last edited 2009-09-18 17:46:19 by 174-20-169-204)