Re: [gdm-list] Request for feedback: Proposed enhancements to GDM greeter interface


I am proposing to do the following work for GDM 2.29 on the greeter code:
1. Produce documentation on the interface between the greeter and the server

This would be very useful.  It might be useful to add a chapter to the
GDM docs in gdm/docs/C/gdm.xml to explain this.  I believe the daemon
and the greeter primarily communicate via D-Bus calls.

However, there is probably some interactions that are assumed that
greeters will do.  For example, how the greeter reacts when GConf
keys are modified, or when files like /etc/passwd are modified.

2. Move code / produce a greeter library to minimise the amount of code in the simple-greeter

This sounds like a good idea.  Some real thought will need to go into
item #2 above.  For example, should this library only include interfaces
that are GUI-agnostic, such as how D-Bus works in the greeter?  Or
should the library contain some GUI elements such as the panel or the
face browser that might be shared across multiple greeters?

3. Produce bindings to the new interface to allow flexible greeter development (e.g. Python/Javascript).


These changes will allow the following improvements:
- New greeters will be able to be developed without limitations - thus making GDM completely themeable

There are some "limitations" that are imposed by accessibility.  So, we
should think about how providing accessibility might affect the
interfaces provided to write a greeter.  We should make it easy for
users to write an accessible greeter.

The old GDM 2.20 gdmgreeter technique of using libgnomecanvas was never
very accessible.  Its GUI elements did not support ATK, and since it ran
without a window manager it did not work well with struts based programs
like GOK.  Hopefully any themed greeters that we develop in the future
will have better accessibility support than gdmgreeter had.

Also, there are some "limitations" that are imposed by PAM.  For
example, some people have suggested it would be nice to display both the
username and password prompts together on the same dialog, but this
would not be possible without significant enhancements to how PAM works.

- A greeter can be developed which is easy for artists to them (e.g. by embedding webkit and using using CSS for theming)

I encourage people to experiment and try new interfaces for the greeter.

However, remember that the login greeter is a program that people with
access to the machine can use without authentication, and the greeter is
used to manage security sensitive information.  So, care should be taken
to ensure that the greeter does not inadvertently give the user any
unintended privileges or access to the machine.

I am all for making GDM easier for artists to use, but we need to be
careful to do this in a way that is also easy to keep maintainable and

- Greeters could be developed for varying hardware to make use of graphics performance (i.e. flashy 3d effects)

Yes, a clutter-based greeter would be interesting.  Though I'd like
to see how gnome-shell deals with a11y before deciding the best way
to go about a clutter-based login GUI.

- Other applications will be able to access GDM information (e.g. application switchers)

Again, care needs to be taken to ensure that other applications do not
gain access to information that is inappropriate.  Since the main GDM
daemon runs as root, there are certain functionalities that greeters
are allowed to do that normal user programs should not be able to do.
Such as how Xauth keys are managed, for example.

I believe GDM is already well integrated into the User Switch applet.
ConsoleKit already provides programs like the User Switch applet far
more useful information than the old GDM 2.20 supported via its
private gdmflexiserver sockets interface.

I would be interested to hear what specific interactions between the
GDM daemon and login greeter you think would be useful to provide
to other applications.  Do you have any use cases you are thinking
about here?

- GDM will be usable by other desktops (KDE, XFCE)

I am not sure I follow what you mean here.  Could you elaborate?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]