converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|= Introduction =||== Introduction ==|
|Line 8:||Line 8:|
|Line 10:||Line 10:|
|= Architecture independent issues =||== Architecture independent issues ==|
|Line 18:||Line 18:|
|= Per-architecture issues =||== Per-architecture issues ==|
|Line 21:||Line 21:|
|== i386 specific ==||=== i386 specific ===|
|Line 25:||Line 25:|
|== AMD64 specific ==||=== AMD64 specific ===|
|Line 28:||Line 28:|
|== PowerPC specific ==||=== PowerPC specific ===|
|Line 34:||Line 34:|
|= Ideas for future development =||== Ideas for future development ==|
|Line 36:||Line 36:|
|== Porting ==||=== Porting ===|
|Line 40:||Line 40:|
|== Fonts ==||=== Fonts ===|
|Line 44:||Line 44:|
|== Usability ==||=== Usability ===|
|Line 53:||Line 53:|
|== Interface design ==||=== Interface design ===|
|Line 57:||Line 57:|
|== Games ==||=== Games ===|
This is an overview of some of the bugs and issues left open or workarounded only in Etch and that i hope will be fixed later in a point release.
Items tagged as pointrelease are desiderata for next Etch pointrelease (mainly bugfixes), all other items refer to issues which will be addressed in Lenny only.
This is no way meant to be an exhaustive list of every bug somehow related to the graphical installer: for a complete buglist see packages cdebconf-gtk-udeb, directfb, libdirectfb-1.0-0-udeb, libgtk-directfb-2.0-0, libgtk-directfb-2.0-0-udeb, rootskel, rootskel-gtk
Architecture independent issues
- Develop real graphical interfaces for components where that adds value. Main example is partitioning.
Try to find a way to present information in columns despite using a proportional font. This may require extensions to the debconf protocol. This should also be generally useful for frontends used in the installed system for configuring packages. done
Input is not handled in UTF-8 mode, some letters cannot be correctly typed. #401296 - done
Support for dead keys was added in DFB post 0.9.25, but GTKDFB does not handle deadkeys anyway, so backporting the DrectFB patch is useless ATM #394871 - done
Plans for Lenny are having cdebconf (C implementation of debconf used in the d-i) replacing debconf in regular debian systems: this will require cdebconf's building system and the GTK frontend being able to build atop of both gtk/directfb nad gtk/x11, see also #402127 - done
We're trying to inventory bugs affecting the g-i on a per-architecture base, architectures considered here are i386, PowerPC, AMD64 .
For historical reasons the vga16fb module is still loaded even if a framebuffer device is already provided by vesafb: this forced us to check that DirectFB actually accesses the framebuffer device provided by vesafb , better would be not starting at all two fb devices concurrently (this also wastes little memory). #401685 - done
Some popular video chips, like intel i810, are not supported by the vesafb framebuffer module and hw-specific modules are not available in the installer, so we cannot currently support those chips. We need to either build into the kernel or provide as loadable modules hw specific framebuffer modules, and load them on the base of the found hardware #405737.
pointrelease The console switching problem on AMD64 #373253 was worked around by adding libgcc1.so.1 via the EXTRAFILES option available in the installer, proper fix requires adding that library via an udeb.
DirectFB linux_input input module cannot correctly detect the keyboard on most ?PowerMacintosh models, so we had to disable it relying on the legacy ps2mouse and keyboard input dr.
This required the inclusion into rootskel and rootskel-gtk packages of some ad hoc startup scripts that take care of picking the correct DirectFB input driver depending on the host architecture.
A prper addressing of this issue requires fixing the linux_input module so that we can switch to linux_input input module for all supported architectures and drop some startup scripts.
Another issue is related to the fact that apparently DirectFB cannot run on top of the nvidia framebuffer: no more information are available because not much light was made on this problem yet.
This thread is about the two above mentioned issues, while a g-i on PowerPC compatibility list can be found here DebianInstaller/GUIPowerPC: feel free to add entries for any configuration that's not yet listed.
The framebuffer device has a fixed size that cannot be set at boot like it's done on i386, so the GTK frontend should adapt itself to go "fullscreen". #401693
Ideas for future development
The graphical version of the installer is currently available for Intel x86, AMD64 and PowerPC. The PowerPC port needs work to get different types of system correctly supported. Other architectures the graphical installer could be ported to include Sparc, Alpha and HPPA.
For font information, please see DebianInstaller/GUIFonts
- Interface should adapt itself so that text blocks are never too wide for optimal readability.
Improve accessability (for the visually handicapped). One way to do this is to support different themes (color schemes). (Note: should not lead to a major increase in initrd size.)
Alternative (graphical) ways to start a shell or browse log files - done
- Logfile-viewer (in split window) in expert mode as default, if screen resolution permits
- Interface design.
- Create custom plug-ins for cdebconf to improve handling of some dialogs and make optimal use of possibilities offered by the graphical environment.
Most of the work on the graphical side has been done by Eduardo Silva. He has set up a webpage with images he designed and some comments about possible future changes.
It would be nice for g-i to have some games to help kill time during lengthy install sessions.
The cdebconf-gtk-tetris udeb is a start, but having a separate entry in the menu does not seem the best way to do it.
Other candidates for inclusion need to have a limited set of dependencies, preferable only those that are already included in g-i, use directfb for graphics, eventually using SDL, sound should be optional, and not need more input device than already detected by g-i.
This excludes c++ implemented games linked against libstdc++, or other language whose runtime is not-available in g-i, as well as all those that link with the gnome libs or other such. A preliminary list follows, out of them, icebreaker sounds like a very good candidate. It is only depending on libsdl, easy to understand, using only the mouse and not the keyboard, and not controversial in any way.
airstrike - 2d dogfight game in the tradition of 'Biplanes' and 'BIP'
atris - tetris-like game with a twist for Unix
barrage - Rather violent action game
black-box - Find the crystals
bomberclone - free Bomberman-like game
bugsquish - Bugs are trying to suck blood out of your arm!
bumprace - 1 or 2 players race through a multi-level maze
bygfoot - soccer (football) manager game featuring the most important European leagues
circuslinux - The clowns are trying to pop balloons to score points!
dangen - shoot 'em up game where accurate shooting matters
icebreaker - Break the iceberg