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


-- 
To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org