Re: [gdm-list] GObject branch

[Brian Cameron <Brian Cameron Sun COM>]

William:

> > Do you think this work will be done in the 2.19 cycle or do you
> > think this will take longer than that?
>
> That is what I was originally shooting for.  However, at this point it
> isn't looking very likely.  Safe bet is to have the branch
> functionally complete by the 2.20 release and merge with trunk at the
> start of the 2.21 cycle.  This will leave a full release cycle to
> shake out bugs.

Are you keeping changes that are going into head merged with your
branch as well, or will such a merge be done later?

> >    http://bugzilla.gnome.org/show_bug.cgi?id=336549
> >
> > > * There is another reworking of the configuration framework.  It still
> > > uses the same desktop file backend.  It is mostly done except for the
> > > change notification stuff.  The new system works a bit like GConf
> > > except the backend only knows strings - all typing and interpretation
> > > of schemas occurs in the client.
> >
> > I'm prepared for the introduction of lots of bugs.  Every time we revamp
> > the configuration system, it seems that a lot of new bugs need to be
> > worked through.
>
> Perhaps.  But the new system has a number advantages here.  For one it
> just uses D-Bus as the IPC mechanism so that eliminates a lot of
> possible bugs right there.  Also the functionality in the backend is
> reduced and made much more modular.  Instead of using a two
> configuration files default and custom there is just a schemas
> definition and the data store file (gconf-ish).  The schemas
> definition is parsed and handed by the client side - so we can use
> asserts to enfore the type etc. contracts.  These will make it much
> easier to make it correct - and find bugs early and easily.

Note that GDM's configuration is declared to be Stable in the GDM docs.
So do we plan to make this backword compatible, or are we talking about
moving to a new major release, such as GDM 3.0?  I'm not opposed to
going to a new major release, but if we are going to do this then we
should consider revamping things further.  There is a lot of cruft in
GDM and code to support backwards compatbility for really old versions
of GDM.  For example:

 - The configuration file isn't well organized.  There is a gui and
   greeter section but the two GUI's are not good about only using
   keys from their section.  There probably should be gui-common,
   gdmlogin and gdmgreeter sections.  For example.

 - Support for old style Face Browser image files.

 - Some configuration keys have backwards compatibility support.

 - The SUP/SOP logic has a lot of deprecated things.


> > What about gdmsetup?  I don't really care much about gdmphotosetup,
> > though some other users might.
>
> Some thought needs to go into how to make a better gdmsetup.  Such as
> how to leverage PolicyKit, how to best use the new gdm settings api,
> etc.

I'd like to see gdmsetup be fixed so it no longer requires the GUI to
run as root.

> The gdmphotosetup functionality should probably just get merged with
> some other tool like gnome-about-me or something...

What about for KDE users and users of other non-GNOME desktops?  This
has been the main reason gdmphotosetup has lingered.

> > > * I don't think I'm going to continue to read the server
> > > configurations from the configuration file but rather talk to HAL or
> > > PolicyKit to determine what seats are available.  We should
> > > dynamically create a display/greeter per seat.  XDMCP works as before.
> >
> > Will this work in a way such that gdmdynamic can add/delete new ones
> > as needed?
>
> Not sure yet but hopefully.  But surely gdmflexiserver will also
> benefit from this...

I hope so.  For Sun to be able to adopt a revamped GDM, this would be
a hard requirement for Sun Ray.

Brian