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

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
GTKDFB 2.8.3.

Ah, cool.

- 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
> unusable.

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 descriptions too. 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.



Reply to: