Attilio Fiandrotti wrote:
Frans Pop wrote:On Monday 02 July 2007 09:34, Attilio Fiandrotti wrote: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.This could be an option, but using debconf for this is probably not the correct solution ("debconf abuse"). Couldn't the frontend "listen" on a named pipe for keyboard change triggers, or something like that? kbd-chooser could then check if that pipe exists and write something to that to indicate a keymap change.Note that as we intend to switch to console-setup, that would have to be made to support this mechanism too.Disclaimer: as this is totally outside my scope, the responsibility to translate this the the correct technical terms and implementation has to lie with others.After evaluating available options, we concluded the GTK frontend has to be signaled from the external (by kbd-chooser or whatever), when DirectFB's keymap has to be updated, and that the keymap reloading call has to be performed directly by the GTK frontend.In my vision, the code inside the GTK frontend implementing the mechanism will be compiled out unless DI_UDEB is defined, so that it remains compatible with X environments when cdebconf is used as a debconf replacement.We must decide anyway how kbd-chooser and the GTK frontend should communicate (although it's one-way signaling, from kbd-chooser to the GTK frontend).Options are 1) by mean of a debconf question (debconf abuse?) 2) by mean of a named pipe or a socket (probably the simplest option)3) by mean of a special question type the GTK frontend handles from within a plugin.
4) As suggested by Jeremy on IRC, reading d-i/keymap while keeping track of last known value and looking for changes.
This is, IMHO, the easiest solution available ATM, and morover doesn't require touching other parts of the installer than the GTK frontend and avoids dealing with pipes.
regards Attilio