Re: Usability issues for the graphical frontend
Frans Pop wrote:
Here is a list of things that have been bugging me while testing the build
system for the graphical frontend.
It is just an unsorted list, not all issues are as important and some
issues may be upstream rather than caused by the frontend itself.
i'll try to collect togheter as much reports about GTK frontend
usability as i can and i'll order them by severity so that most
important are solved earlier.
Here i'll try to give some preliminary answers (and this helps me to
make the point of the developement status, too...)
It would be nice to get some comments on these so we can decide what we
can fix ourselves and what proper bug reports need to be filed where.
I think for a while still wanted improvements to the frontend should not
yet reported as bugs: this would lead to a huge number of bugreports
while resolving them there is faster (i plan to work a lot on this next
I would really like to see the progress bar in a separate window
(should be always on top and window below disabled).
Having it permanently visible makes no sense to me. This may be
difficult as components do not always use the progress bar properly
(e.g. leaving it open when another dialog is shown), but that could
i agree with you: anyway today i realized we would have to face the
problems of questions diplayed between progressbar runs without
htk_progress_stop() being called.
many debconf clients in d-i act this way and to be able to manage those
situations the FE needs some more code.
ATM having the prograssbar always displayed get us rid of the problem (i
can now remember this is the main reason i moved the progressbar in the
screen to be permanently displayed)
Order of the elements on screen
- text area should be above question area as the text area is mostly
an introduction to the question
Ok, this is possibl to do without problems, but this way the question
would be displayed at a vertical starting point always different,
depending on the extended question description
- title for progress bar should be above the progress bar, not below
this is exactly the case of the NEWT interface, but HIG 2.0 tell the
opposite: more widely we should choose if to try to imitate the newt
frontend in everything or follow HIG suggestions to build the GTK FE.
- text area should be skipped when using tab
yes, i agree
- continue button should be before go back button (in tab order, not
Issues with questions
- when a new screen is shown, the first question should be active
maybe i've forgot to activate this when i wrote the most recent SELECT
- when you "tab" into a list question, the default is always set to
the top of the list instead of the current default value; the
current default should be respected and the frontend should make
sure it is shown by scrolling the list if needed
(example: select English as language and when
- lists do not scroll automatically if cursor keys are used to select
an item (try PgDn in language list)
boths bugs are related to GTKDFB 2.0.9: the needed code is already
inside the frontend and works correctly with GTKX (any version) and
Maybe this bug should be reported to Mike Emmel togheter with some other
ones i noticed.
- the continue button should be default and activated on enter for
most types of dialogs
- it'd be nice if you could "select and continue" with double click
i think Eduard is right when fearing about accidental double-clicks...
- it'd be nice if you could select in lists by typing the first letter
(as in newt frontend)
good idea, this should be added
- ideally the title of a long list should be fixed at the top and not
scroll away; hmmm, this is probably because the question area does
not contain a single question, but all questions...
already solved in my last updates (not yet in SVN), while the GTK
frontend can still handler multiple questions togheter
>For "note" templates, the text is shown both in the question area and
>text area. Should be only the text area IMO.
this is due to an hack that displays again the qestion's description
inside the help area if the question misses an extended description.
the hack is there just to prevent empty help areas to be displayed to
I think EVERY question should have an extended description now that we
have the GTK FE that allows for it to be displayed.
>If you switch to VT2 (shell console) while the frontend is running, the
>frontend will "hijack" VT2 making the installer completely unusable.
but if you press ctrl+alt+f5 (or f6?) you can go back to the FE..
and i would also like to add
-during language selection native language names should be aligned
-in the partman's main question partitions should be displayed as childs
to disks drives
-the partman's main question has a too long description: this should be
made shorter and text in excess moved to the extended description field,
that now is empty
-multiselect questions should be handled by a gtktreeview rather than by
a list of gtkcheckboxes when only a question is displayed
Anyway having a list of TODOs helps a lot: if someone find more
usability issues or bugs in the GTK FE feel free to post!