[Top][All Lists]

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

Re: [GITGRUB] New menu interface (implementation)

From: Michal Suchanek
Subject: Re: [GITGRUB] New menu interface (implementation)
Date: Mon, 21 Sep 2009 11:23:14 +0200

2009/9/20 address@hidden <address@hidden>:
> On Sun, Sep 20, 2009 at 3:31 AM, Michal Suchanek <address@hidden> wrote:
>> 2009/9/19 address@hidden <address@hidden>:
>>> On Sat, Sep 19, 2009 at 1:45 PM, Michal Suchanek <address@hidden> wrote:
>>>> Hello
>>>> why does the menu system have a glyph drawing function?
>>>> Is the one in font.c not suitable?
>>>> Why are there two methods for returning text width and height, one in
>>>> gfx_region in pixels, the other in text_region in characters? Does
>>>> size in characters make any sense? There might be proportional fonts
>>>> or at least fonts of different size in the future.
>>> Pixels and proportional fonts are meaningless to a serial console.
>> So is element placement.
> I know of multiple systems that support multiple columns, status bar,
> menu bar, popup dialogs, etc in text mode over a serial connection.
> If those things are considered out of scope for a bootloader, I'd tend
> to agree.  But people seem to be defining rich interfaces for grub and
> to do so requires the ability to measure sizes in characters.

Certainly, the Linux console also emulates what once used to be a
serial terminal.
The problem is that there are many types of different terminals and
terminal emulators which makes this somewhat difficult.

For this to work we would need

1) something like curses and its terminfo database in grub
2) know which terminal is connected to grub

Since (2) cannot be reliably determined by grub we must support the
case when the terminal is unknown and only very simple formatting can
be used (dumb terminal). It may be nice to use something like curses
when the user does configure the terminal type but I think this would
be very rare use and need not be part of the menu system initially. It
should be easy to adapt the code that deals with text mode for this
case if desired.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]