|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: Reworking the GTK+ cdebconf frontend
Date: Mon Jul 02 2007 - 03:34:20 EDT
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
-- To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.orgReceived on Mon Jul 2 03:30:53 2007
This archive was generated by hypermail 2.1.8 : Mon Jul 02 2007 - 03:40:03 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |