Re: Usability issues for the GTK graphical frontend, categorized and updated list
On Tue, Oct 25, 2005 at 01:20:16AM +0200, Attilio Fiandrotti wrote:
> >>Since the main screen, after removing the helpbox and static
> >>progressbar, will have to display a smaller number of elements at the
> >>same time then the GTK FE could operate using a 640x480 resolution
> >>rather than the current 800x600.
> >
> >Yes. Also, with the logo moved to the top and the textareas gone, the text
> >is getting too wide to read easily. We should do something about that,
> >for example by defining a left and right margins (or maximum width for
> >text area) for higher resolutions.
>
> this can be easily done by defining a different QUESTIONBOX_HPADDING in
> gtk.c.
> Switching to 640x480 will require us to modify the window's width/height
> in gtk.c and to set the correct vga=xxx parameter at boot time
Just a quick note, i don't know about the vga=xxx stuff, but most real
framebuffer devices (like radeonfb, the most used on powerpc) use a different
syntax : video=radeonfb:800x600-8@60 or to be more exact :
---- linux/Documentation/fb/modedb.txt ----
Valid mode specifiers (mode_option argument):
<xres>x<yres>[-<bpp>][@<refresh>]
<name>[-<bpp>][@<refresh>]
with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
Things between square brackets are optional.
-------------------------------------------
Furthermore some framebuffer devices, like the above mentioned radeonfb know
how to set the resolution automatically to the max supported one, presumably
only for LCD screens, didn't test in ages on CRTs since i don't have one
anymore. The framebuffer devices probes the monitor on DDC, and parses the
EDID field to get that info. It happens sometimes that the monitor lies about
its supported modes and/or the info is not available (non DDC supporting
monitor) and that there is thus out of sync output. This i believe needs to be
documented somewhere, or something.
Friendly,
Sven Luther
Reply to: