[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Usability issues for the GTK graphical frontend, categorized and updated list



Hi

during past days a lot of usability issues about the GTK frontend were reported on this mailing list.
I've now collected them all togheter and categorized them by subject.
Note that the frontend will be used mosty to display single questions, so it may be optimized for such an usage, but it must still look nice even when multiple questions are displayed togheter.


ciao

Attilio


*Issues related to the help area

-The help area (the white box where a qestion's extended description is diplayed) should be displayed above the questions rather than below (this because many extended descriptions refer to questions as "The above question.." as they were tought to be visualized using the NEWT frontend) Im my private tests i've moved the help area above the actionbox, changed background colour to GTK standard gray and removed frame: this looks nice when single questions are diplayed. In the future optimum would be having extended descriptions diplayed abobve every single each question even when multiple questions are to be displayed togheter. This would require removing the global GTKTextArea and placing a multiline GTKLabel above each question, a label that shall be destroyed togheter with the question handler widgets(s) after gtk_go() terminates. This would allow us to no longer have to detct mouse passage over questions to update the help area (this i remember was somehow broken in GTKDFB 2.0.9)

-Some questions lacks of a proper extended description: ATM an hack repeats the question's description in the help area in such cases and this hack will be soon removed. Anyway EVERY question, as recomended by the debconf protocol, shoud be provided by an appropriate extended description (especially now that the GTK frontend allows to display it togheter with the question)

-Some extended descriptions include Blank lines between text lines: this was needed with the NEWT frontend but makes no longer sense in the GTK frontend, so blank lines should simply not be diplayed in the help area. Note that having to display too long extended descriptions will force the question to be diplayed in the bottom part of the screen rather than in the middle, so blank lines-removal is needed.



*Issues related to SELECT questions handler

-RTL patch by Eugeniy works for almost everything inside the frontend except for text inside GTKTreeView widgets: this problem shall be solved.

-The SELECT handler should vertically align translated languages names.
This can be quickly implemented in an hacky way or, in a more proper way, by using plugins

-it'd be nice if you could select in lists by typing the first letter (as in newt frontend)

-lists do not scroll automatically if cursor keys are used to select an item (try PgDn in language list)



*Issues related to TAB navigation of the interface

-TAB navigation should activate the Continue button before the Back button

-text area should be skipped when navigating the interface using TAB

-Continue button should activated by default (so that simply pressing SPACE or RETURN will select the default question's option)

-when a new screen is shown, the first question should be active (this feature should be already present, i'll investigate on the cause why it fails)



*Issues related to progressbar

-The progress bar should be moved to a modal popup window or something like this (basically should not be continuously displayed on the screen). To achive this we must handle in a clever way situations where client debconf apps do not call gtk_progressbar_stop() after updating the progressbar and before asking a question (more precisely before calling gtk_go() ). Shall the progressbar be NEWT-like (title above it, current action below it) or GNOME HIG-compliant (current action displayed inside the progressbar, title displayed above it) ?

-Progressbar should correctly display very long action descriptions



*Issues related to partman

-In the partman's main menu partitions should be displayed as childs to disks drives: this can be obtained by hacking a bit the frontend in order not to have to change the partman templates

-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 is now empty



*Various
	
-If you switch to VT2 (shell console) while the frontend is running, the
frontend will "hijack" VT2 making the installer completely unusable.
THis bug was reported to show up under some circumstances, more investigations are needed
Note that this only happens if you switch when the frontend is busy!
There is no problem if the frontend is waiting for input.

-multiselect questions should be handled by a gtktreeview rather than by a list of gtkcheckboxes when only a question is displayed.
This to 	



* Issues not strictly related to gtk.c

The following reported bugs are not related directly to the implementation of gtk.c () but rather to GTKDFB 2.0.9. The following bugs do not show up under GTKX (any version) nor GTKDFB 2.8.3 and a bugreport has already been sent to Mike Emmel

- 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)



*Plans for the future

-Merging the gtk-miniiso in the main d-i tree: before this some bugs reported by frans pop must be solved

-Packaging fonts in regular udebs rather than tarballs: help by font mantaners is needed, has someone calready contacted them?

-Switching to GTKDFB 2.8.3.
This will be tought, since many libraries (cairo, ..) have not yet been packaged into udebs and preliminary testing on integration is still to come. Anyway benefits will be many and GTKDFB 2.0.9, altough working, is very updated

-Testing on archs different from i386 : ATM this is the only arch where miniiso images are knows to be built correctly. EddyP is known to have made some experiments on PPC but it seems he's stuck with segfaults that prevent the frontend from working properly.



Reply to: