Re: [gdm-list] Approaching GDM 2.21/2.22

[Brian Cameron <Brian Cameron Sun COM>]

Lukasz:

> It might be good idea to provide some backward compatibility with the 
> greeters, more of a visual one, the internals could be completely 
> changed.

I agree that continued support of the theme XML format is desirable,
even though I've heard many people tell me that they could live without
it.  I also don't think Jon was suggesting that we avoid updated
gdmgreeter (or gdmlogin).  I think he was more saying that we need
to use the simple greeter as a starting point, and add on the
features we want.

Fortunately the greeter code is somewhat modular and much of its
functionality is separated.  In detail:

greeter          - main loop, initialization, IPC, and cruft
greeter_parser   - handles parsing of the XML file
greeter_canvas_* - handles the GnomeCanvas items.  Probably should be
                   enhanced to use cairo instead of libgnomecanvas, but
                   we can continue using libgnomecanvas for now.
greeter_events   - handles how items in the XML trigger events to
                   launch greeter_item* things.
greeter_item_*   - handles the special case types in the XML file,
                   such as clock and the pam-entry field.
greeter_system   - Handles the System Menu
greeter_session  - Handles the session choice dialog.
greeter_dialogs  - Manages displaying dialogs

So, it shouldn't be that impossible to add the above functionalities
into the simple greeter or a subclass of the simple greeter.  It might
make sense for a subclass to have the additional functionality of knowing
how to parse the XML and have the greeter_parser code.  This would make
reusing and extending the XML format easier.

So, the only file that really deals with the IPC stuff is in greeter.c
which is still an ugly 1700 lines of code.

Also, the IPC logic in gdmgreeter and gdmlogin is a real cut-and-paste
job.  It would make the code better if this were separated into
separate files, or into a base class.

Note, I won't cry if we lose gdmlogin, but if we do that, we should
fix some of the more serious accessibility issues in gdmgreeter.  It
might be easier to port gdmlogin for the next release than to deal
with these issues, but we'll see what time allows.

> This probably is more to do with gdmgreeter as there are a lot 
> of people with different themes that they want to use. Providing such 
> compatibility would convince people to switch quicker (i.e. "hey we have 
> new gdm - its better, it has more features and you can still use your 
> favourite theme(s)"). What i would like to do is (please let me know 
> what you think):

I agree, and I don't think it would be that hard to replace the existing
IPC stuff with the new IPC stuff, though it is a bit of surgery.  A
bigger headache is that if we get gdmgreeter working, we'll probably
expose a lot of bugs in the daemon/slave when we start to exercise new
code and discover what bugs are there, and what functionalities were
lost in the rewrite.  Hopefully, not many, but I suspect fixing these
bugs will be more work than actually converting the greeter.

> * Have a gdmgreeter base class that will be used by all the greeter and 
> will deal with all the core elements of the greeter functionality (i.e. 
> handling the communication aspects, loading of config values, 
> interacting with pam, e.t.c) and upon which all greeters will be built. 
> This should provide a common code for all the greeters and make 
> imlementation of custom greeters easier.

I agree.  A subclass that also supports parsing the XML format and
triggering events (greeter_parser and greeter_events) would probably
also be useful.  That way other people could write greeters that used
the same XML format.  If someone wants to come along and write a cairo
greeter, for example, it might be easier if we can modularize the code
so that all the cairo code is more centered in one place.

> * Have a separate config file for each of the greeters which will 
> contain the interface side of the configuration (i.e. Theme settings, 
> presence of logos, menus, position of the window, etc). This info can 
> then be removed from the main config files. This should make writing of 
> the greeters much easier and should integrate nicely with the gdmsetup.
> Alternatively we could have a separate section for each of the greeters 
> in the main config file that deals with the interface issues.

Or perhaps different sections in the configuration file for each gobject
and subclass.  This way, when you subclass the greeter, you can just add
a section to the configuration file, or add a new configuration file or
whatever, and the infrastructure would just deal with the configuration
the way you would expect.  That would be cool, and much better organized
than how the GUI configuration options are currently laid out.

This would badly break ABI compatibility for the configuration file,
though.  So, I'd recommend we hold off on redesigning the configuration
section until after we get the existing code working.  It will probably
be more clear then what we will want to redesign anyway.  Then rewriting
the configuration could be for GDM 2.24 or GDM 3.0.

> Yup im in :). There has been some lesson learned from the bugs of 
> current gdmsetup so i hope we can avoid some pitfalls in the new one. 
> PolicyKit sound like a good idea.

Yes, would be nice if we could launch gdmsetup via something like
PolicyKit so the GUI doesn't have to run as root.

> Also i would like re-design how
> gdmsetup looks. I was thinking of dividing the interface into two 
> sections, one narrow column containing the icons of the "sections" and 
> the main area which will contain corresponding tabs/other gui widgets. 
> Atm i can think of four Sections:
> 1. Basic
> 2. Advanced
> 3-? Greeter related stuff - one section per greeter (the separation of 
> the gui config info mentioned above would come in handy here)

This approach has been recommended by the GNOME usability team for some
time, though nobody has yet figured out, in detail, what is a good
division between what is Basic and Advanced.  It would be great if you
were to take a stab at that.

> What do we do about existing gdm in terms of fixing bugs - there are few 
> things I'd like to tackle (mainly related to custom commands and 
> gdmsetup) but I'm not sure if this is wise as dividing the attention 
> between the two might cause a delay for the new gdm

I would recommend focusing your attention now on the new GDM, unless you
feel a bug is particularly serious.  I think it is possible that we could
release the new branch for 2.22 and fixing bugs there will help achieve
that goal.  We should backport bugs to 2.19/2.20 only if we know there is
a strong need, or if it is trivial to patch the 2.19/2.20 code with the
same codechange as applied to head.

I plan to do minimal work in the 2.21 branch until we can merge back in
the code from the gobject-branch.  If we don't get it done in time for
2.22, this simply means that there won't be much new features or bug
fixes in the 2.22 release.  Probably only critical things, and fixes
provided from the community, things we just can't resist fixing, etc.

I am open to the idea that some interface breakages could be allowed in
2.22.  When we have a better idea of what might be too difficult to port
to the rewrite, we can discuss how we will manage any interface breakage
we might be introducing.  This way, if someone in the community feels
they really need a feature we're thinking of dropping, then they can get
involved to help address their needs.  So, as much as possible, we get
things right for the 2.22 release.  If this means that we end up shipping
GDM 2.22 a bit late on the GNOME schedule, or if the features don't go in
until 2.24 or whenever, so be it.

Does this seem like a reasonable plan to everyone?  These are my thoughts
anyway.

Again, thanks for all the support everyone.  It's great to be working on
a project where it feels there are a team of people working on different
areas.

We should probably chat about our design ideas for GDM a bit more on this
list, in general, since that would help us work together in a more teamlike
fashion, I think.

Ray, do you have any thoughts?  Or, anyone else?

Brian