Re: Usability issues for the graphical frontend
Frans Pop wrote:
On Thursday 20 October 2005 22:15, Attilio Fiandrotti wrote:
- 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.
Not true. The text you display _inside_ the progress bar is below it in
the newt frontend, but the title is above it.
The newt frontend has a percentage inside the progress bar.
I suppose because of limited number of characters displayed on screen by
the NEWT FE it was actually impossible diplaying more than a percentage
inside the progressbar.
vice-versa GTK FE allows more complex text to be displayed inside the
progressbar, so i suppoese we should take advantage of this and develop
an HIG compiant frontend rather than trying to imitate the NEWT interface.
As often pointed out in the past the GTK FE should be a real improvement
if comparet to the NEWT FE and not just a graphical revisitation of it
(then newt2gtk libraries would have been enough ;)
It would even be preferable to do it the same way in the GTK frontend as
the fact that the text is centered in the progress bar makes it jump
around and thus harder to read. It would also make it possible to wrap
longer texts to the next line.
GTK >=2.6 offers gtk_progress_bar_set_ellipsize() function that could be
useful to solve the long lines problem: i would suggest to wait for the
switch to GTK v 2.8 to decide what to do on this
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
- 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
committed to SVN. comes to my mind only now that single MULTISELECT
questions could be better displayed with a GTKTreeView-based handler
rather than the current one that relies on multiple boolean checkboxes.
Anyway this improvement is not essential ATM.
>If you switch to VT2 (shell console) while the frontend is running,
> the frontend will "hijack" VT2 making the installer completely
but if you press ctrl+alt+f5 (or f6?) you can go back to the FE..
No, that screen remains black and the FE is restarted in VT2 as soon as
you try to type something there.
this is strange: on the desktop pc i use for testing the miniiso images
the crash does not happens, maybe a DFB bug?
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
Sure, but these were already known issues, so I did not include them.
-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
If you mean changed in the partman source then we can only do that if it
is still displayed correctly in the newt frontend.
Yes, this should create no problem with the NEWT frontend, only the
question description will be shorter since some text will be moved to
the extended description.
We should also mind that the debconf protocol recomends to display short
texts only in the "description" field of a question and to always fill
the "extended description" field with detailed question descriptions.
This seems wise to me, but in the past programmers of debconf
applications in d-i may have been forced to create long question
descriptions since the Newt frontend cannot easily display extended
question descriptions because of the limited number of chracters
displayable togheter on screen (you've got to press the help button that
opens a new popup window).
Now that the GTK frontend has solved the problem since it can display a
question's description and extended description togheter in the same
screen developers of debconf client apps have the opportunity to give
the user better support by implementing long question extended
This will require time and contributions by the translators too, but
getting the most out of the GTK frontend will be advisable as soon it
becomes a standard for Debian installations.