Re: Reworking the GTK+ cdebconf frontend

[Loïc Minier <lool@dooz.org>]

On Thu, Jun 28, 2007, Attilio Fiandrotti wrote:
[...]
> The cleanest solution would probably be delegating keymap reloading 
> (acually, the calling of dfb_input_device_reload_keymap() ) to an 
> external application, called by the a debconf client only when needed, 
> and not by the frontend.

 Hmm this looks rather like a workaround which might require a restart
 of the frontend and wouldn't seem very clean to me.

[...]
> Because keymap reloading may be a common issue for other gtk/dfb based 
> apps, i think a reasonable way to proceed is adding a
> 
> gdk_directfb_keymap_reload()

 Would there be a X11 equivalent for this?  I'm not sure I agree Gdk
 needs to gain a directfb specific function concerning keymap reloading,
 nor that manual reloading is the way to go.

 Gdk has some API regarding keymaps, but mostly getters and no setter.
 It also seems to provide a way to detect when a keymap changes via the
 ::keys-changed signal.
   Isn't there a way to make directfb triggers the internal gdk keymap
 reload mechanism without adding a manual reload API?  This would save
 the cdebconf frontend and other gtk/gdk apps the trouble of manually
 reloading the keymap.

> This would save us from including directfb's header files from the GTK 
> frontend and directly calling directfb functions from within it.
> I could propose a patch and apply it upstream, but i'd like to hear an 
> opinion from our gtk/dfb maintiner: Loic,  what's your opinion on this 
> issue?

 I don't see the problem in including the directfb headers from one of
 the file used to build cdebconf/gtk: can't you have
 cdebconf/gtk/common.c, directfb.c, and x11.c?

-- 
Loïc Minier