Re: [gdm-list] GTK theme for thegreeter screen?




Sebastien:

gdm.conf has that comment:
"# If to allow changing the GTK+ (widget) theme from the greeter.
Currently
# this only affects the standard greeter as the graphical greeter does
not yet
# have this ability."

Is there any technically reason that applying a theme works for the
standard banner but not the greeter one? Do you have any idea of what
change would be required for that?

Currently the only way for gdmgreeter users to change the theme
using a GUI is to run gdmsetup from the login screen, although you
need to know the root password and GDM's configuration has to be
setup to allow running gdmsetup from the login program.

The reason that we support changing themes for the gdmlogin program
is that some users require the accessibility themes (high-contrast,
low-contrast, etc.).  These themes only have meaning when using gdmlogin
which uses GTK+ widgetry whereas gdmgreeter uses libgnomecanvas and
does not really use GTK theming much, if at all.

Many users with accessibility needs can only use gdmlogin and not
gdmgreeter for a number of reasons.

1) gdmgreeter has no real mechanism to support switching the theme to
   high-contrast/low-contrast/etc. and even if it did support this
   feature, gdmgreeter does not yet have any high-contrast/low-contrast
   themes.  So they would need to be designed and included with
   GDM as well.

2) gdmgreeter does not have a window manager running while gdmlogin
   has the "light" window manager implemented in gui/gdmwm.c.  This
   supports STRUTS and allows AT programs that need to launch a GUI
   (such as the magnifier) to work properly and never obscure the
   login prompt (for example, if the magnifier is run in half screen
   mode the GDM prompt moves over).  I'm not sure how the gdmgreeter
   theming would manage this sort of need.  Perhaps this could be
   addressed by making gdmgreeter use the gui/gdmwm.c code and
   defining the whole gdmgreeter screen as a "window" that would
   resize to fill half the screen if something like the magnifier were
   launched.  This might look ugly, though, since most themes are
   designed to fit on the screen and the screen dimensions change
   when part of the screen is filled by something else.  This might
   require some work to enhance the gdmgreeter theme XML format to
   manage resizing without looking ugly.  Not sure.

3) gdmgreeter doesn't use GTK+ button widgets so it doesn't take
   advantage of the ATK implementation that comes with GTK+ buttons.
   gdmgreeter's buttons are just window areas that respond to mouse
   clicks managed by event handlers in the gdmgreeter code.  This
   would need to be changed to use real GTK+ buttons or gdmgreeter
   buttons would have to directly implement the ATK button interfaces.
   There may be other similar widgetry issues with using a
   libgnomecanvas style GUI, such as entry fields not having
   AT-visible labels that would also need to be addressed.

It would be cool if people were interested in improving gdmgreeter so
it could be used by accessible users, but I think the above issues
is enough work that it will probably take a good while before
gdmgreeter is a real option for such users.  And since they can just
use gdmlogin today, perhaps there isn't a real need here to make
gdmgreeter accessible.

Enhancing gdmgreeter so users can switch the theme would get us one
step closer, but probably isn't as hard as dealing with issues #2
and #3 mentioned above.

Though I'd probably recommend that if this feature were added that it
be turned off by default (like it already is for gdmlogin).  It probably
makes sense for somebody to tweak the configuration if they want users
to be able to switch the theme from the login screen without knowing
the root password.

Hope this helps explain why the code works as it does.

Brian




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