Re: [gdm-list] Branch update

[Brian Cameron <Brian Cameron Sun COM>]

Oswald:

> an actual common project would be faced with certain management
> difficulties - the backend + a desktop's frontend(s) need to be released
> with the desktop itself (at least for kde) - i don't think kdm having
> "extragear-character" would be that welcomed.

I don't understand what you mean by "extragear-character".  Could you
explain?

> dependency-wise it is clear that the backend must not use more than glib
> (and gobject, if it must be) from the gnome side (yeah, yeah, we don't
> care how *you* see glib ;). libintl, xlib (and xcb), some minor libs -
> that's it.

Looking at ldd of gdm-binary on the new mccann-gobject branch, there
does seem to be some places where gtk/gtk.h is included, to make use
of the GDK_WATCH symbol.  This probably is a bug since it does cause
GTK+ and related dependencies to get sucked in.  Probably not worth it
for just this one symbol.

> - i always thought gdm's internal ipc over the fully-fledged socket
>   protocol is completely overengineered. d-bus is taking this to another
>   level ...

It's probably better to use a standard IPC method like D-Bus than a
home grown one.

> two things should be clear to you:
> - i accept no regressions from current kdm

When you say "no regressions" what do you mean?  Do you mean in terms
of functionality alone, or also with appearance?  If there are any
novel features that KDM supports that might not be obvious, then it
would be handy if you could mention some that you think might be
easy to overlook.

> no, you bcc'd me, which isn't very clever for spam classification
> reasons. ;)

Sorry about that.  But I'm glad that you were able to join in on
the discussion.  Is there a better way to communicate with the
KDM team about opportunities to work together, or is emailing you
directly the best way?

Brian