Re: Switching g-i from DirectFB to X11 -- console-setup
On Monday 08 February 2010, Cyril Brulebois wrote:
> - Maybe think of switching over from kbd-chooser to console-setup. It
> should work (almost) out of the box for X11 (that was at least OK
> with my very first image, before cleaning up my patches), while
> kbd-chooser would mean patching some more.
I agree that console-setup-udeb is a much more natural choice for an X.Org
based graphical installer than kbd-chooser.
I was somewhat surprised to see x11-xkb-utils-udeb and especially the very
large xkb-data-udeb. Isn't there an overlap with the console-setup udebs?
If there is, it would be good to get rid of that overlap.
> And AFAICT console-setup should be able to handle both X and non-X
> cases.
The main issue with console-setup-udeb is usability. If I would have to
rate it for usability console-setup-udeb would get no more that 3 out of
10. Please note that that is just my personal optinion and limited to the
use of c-s for D-I; I have no opinion on the usability of c-s for the
installed system.
It offers way too many choices, most of which are totally irrelevant in the
context of an installation, even in expert mode.
Besides that it offers choices for keymaps that are not even available and
AFAIK it does not detect headless systems that don't need any console
setup. I also don't like parts of the technical implementation.
The extremely long selection lists make console-setup-udeb completely
unusable with the text frontend [1].
The basic error in the design is the assumption that the same functionality
is suitable for both installed systems (where users may want to tune there
keyboard for their personal preferences and, most importantly, have the
opportunity to try out different options and see their effect) and for the
installer (where users only need a basic selection of the correct keymap
with solid defaults based on country, language and keymap for everything
else).
Of course both deb and udeb should use common code where possible, but IMO
the options offered in the udeb should be severely reduced.
I'm not going into further detail here. For that, please see the earlier
thread Samuel already linked to.
Having said all that, I don't see any need to block progress on the X.Org
implementation because of this. The c-s udeb works well enough that it can
be used. My preferred solution would therefore be to switch to c-s udeb
*only* for the graphical installer and stay with kbd-chooser for the
regular installer until the integration of the c-s udeb in the installer
has been improved.
Implementing this option is fairly straightforward with the following in
pkg-lists/gtk-common:
# Use console-setup
console-setup-pc-ekmap
console-setup-udeb
kbd-chooser -
console-keymaps-at -
Added advantage is that the console-setup udeb will get more exposure and
because of that maybe more attention.
Cheers,
FJP
[1] I don't mean the newt frontend, but what you get when booting with
DEBIAN_FRONTEND=text.
Reply to: