Re: Reworking the GTK+ cdebconf frontend

[Attilio Fiandrotti <attilio.fiandrotti@gmail.com>]

Loïc Minier wrote:

<snip/>

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


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

If we were on X, we could probably use setxkbmap to tell the X server
the keymap had changed.
Because we are on DFB, and because we haven't multicore support enabled
 in our directfb builds, we cannot tell the master DFB process the
keymap has changed unless from within the cdebconf process.
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.

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

Because we can now detect whether to enable or not DirectFB code by mean
of the DI_UDEB check, the best solution is probably leaving the
dfb_input_device_reload_keymap( dfb_input_device_at( DIDID_KEYBOARD ) );
call where it is, and probably fixing the compiler warining with Lunar's
patch.

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);
}


So that we don't pollute the output of the GTK frontend with
unneded messages related to keymap reloading anymore.
This fix to work requires of course updating both the keymap-chooser and
gtk frontend toghether.

I'd like to hear opinions on this solution.

regards

Attilio Fiandrotti