Re: Reworking the GTK+ cdebconf frontend
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
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
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
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?