libgswitchit + libkbdraw => ... ?

["Sergey Udaltsov" <sergey udaltsov gmail com>]

Hi all

There was interesting discussion tonight on #g-h, so here I'll give
some summary and ask an advice:

As some of you might be aware, libgswitchit and libkbdaw are virtual
modules included into gnome-control-center and gnome-applets. They
include some shared code:
1. dealing with keyboard configuration in GConf (depends on
libxklavier and gconf)
2. keyboard information DBUS server and client API (depends on
libxklavier and dbus)
3. indicator gtk widget (rather heavy, using #1 and #2 as DBUS
client). Includes plugins API and plugin management capplet
4. keyboard layout display gtk widget, libkbdraw (depends on gtk)

Usage of this code:
- gnome-settings-daemon uses #1 and #2 (server)
- gnome-keyboard-properties uses #1, #4
- gnome-keyboard-applet uses #3 (and indirectly #1 and #2, DBUS client API)

Potential usage - any application which would like to use indicator
widget (for a momen - gnome-screensaver is proposed) will use #3 (and
#1 and #2, DBUS client API)

Initially, I proposed to put the stuff into libgnomeui (since there
are 2 gtk widgets involved). But then Ben Maurer went into the
conversation and made several substantial notes:

- libgnomeui is very bloated as such. LIBS=-lgnomeui makes
applications MUCH heavier.
- adding dependency on libgnomeui (and any gtk code) to
gnome-settings-daemon is a very bad thing (g-s-d ideally should be
headless)

So, Ben advised to create two small libraries - one for gui-less stuff
(#1 and #2) and one for gtk widgets (#3 and #4). This would be the
best solution from the performance POV.

I see the Ben's point but I have strong concern that solutions like
this could easily make GNOME any distrobuilder's nightmare.

So here is the question: would gnome build process stand 2(!!!) new
TINY(!) libraries - or is there better way to handle this?

Comments are welcome,

Sergey

PS Ben, thanks for your participation and sorry if I missed some of
your arguments