Re: [gdm-list] GObject branch

["William Jon McCann" <mccann jhu edu>]

On 6/5/07, Brian Cameron <Brian Cameron sun com> wrote:
> 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?

No, I haven't done any merging from head.  This will actually be
non-trivial because the changes are quite extensive.  I guess we'll
have to carefully look at each change to head since the branch and
merge each one if it is applicable.

> >>    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:

Yeah, this will probably be a 3.0.  I decided to branch in part
because, frankly, there is so much that just isn't worth keeping.  So,
GDM2 may be considered stable but obsolete.

>   - 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.

Sure, I guess.

>   - Support for old style Face Browser image files.
>
>   - Some configuration keys have backwards compatibility support.

Yeah we should remove them.

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

SUP and SOP are completely removed in the branch.

> >> 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.

Me too.

> > 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.

Dunno... not our problem per se.  The most important thing is to come
up with a standard way of specifying the photos (which for now is just
~/.face).

> >> > * 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.

Yep.

Jon