Re: Reworking the GTK+ cdebconf frontend

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

On Mon, Jul 02, 2007, Attilio Fiandrotti wrote:
> The core of the problem is not detecting the keymap change at the toolkit 
> level (which is unimportant in our case) but rather informing the windowing 
> system (DirectFB in our case) that the keymap has to be updated to match 
> the console one set by keymap-chooser (or whatever is the d-i component 
> performing that task).

 Well, s/toolkit/windowing system/: why not work on making the windowing
 system aware of keymap changes rather than adding API to force a reload
 manually?

> If we were on X, we could probably use setxkbmap to tell the X server
> the keymap had changed.

 Hmm you could use setxkbmap to *change* the keymap of the server, and
 you wouldn't have to do anything in each client.  It's precisely
 thinking of the X model that I was surprized you wanted to add API to
 do more things manually, and it's only fixed at the toolkit level, for
 this toolkit, instead of the lower levels.

> From within the cdebconf process, there is unluckily no easy way to
> detect / being informed that the console's keymap has changed.
> So, what we do is forcing, from the gtk frontend, keymap reloading at
> every frontend::go() call.

 What channels could we use to inform directfb of keymap changes?  Would
 it be possible to make whatever first process controls the FB listen on
 some agreed upon socket location and send some "the keymap has been
 reloaded" messages to it when the relevant "change keymap" binary is
 run?  Or perhaps the kernel can send such events, as I understand it's
 the layer where the switch happens?

> A reasonable improvement over current situation could prbably be setting 
> TRUE a boolean "d-i/keymap_changed" question from within the keymap-chooser 
> everytime the console keymap is updated.
> At every frontend_go() call, the gtk frontend should do something like
> (pseudocode)
>
> if ( question_get("d-i/keymap_changed") == TRUE ) {
> 	dfb_input_device_reload_keymap( dfb_input_device_at( DIDID_KEYBOARD ) );
> 	question_set ("d-i/keymap_changed", FALSE);

 This would only work for debconf aware programs having this snippet and
 if all keymap-changing programs are made debconf-aware too.  The
 advantage of a lower-level solution would be to enable this detection
 for all situations.

 IOW: how do keymap-changing programs inform the DirectFB layer that the
 keymap has changed and it should reload it (transparently for any
 higher layer)?

-- 
Loïc Minier