Re: pretty colors in gfxterm

["Yoshinori K. Okuji" <okuji@enbug.org>]

On Tuesday 08 May 2007 22:19, Otavio Salvador wrote:
> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
> > On Tuesday 08 May 2007 15:36, Robert Millan wrote:
> >> > I don't have much time, either, but I will refactor the menu code
> >> > sooner or later. Once this is done, it wouldn't be too difficult to
> >> > implement new intefaces for the menu.
> >>
> >> Other (perhaps easier) options that would also improve the situation are
> >> "hiddenmenu" and splash image support.
> >
> > I don't want to have ad-hoc features in GRUB 2. I have studied that
> > ad-hoc harms.
>
> Sorry but I didn't get what you mean by 'ad-hoc features' here. Can
> you elaborate it, please?

Features, which are not fully examined if they are generic, flexible and 
extensible, are all ad-hoc. As I said in this list some times, I believe that 
the user must be able to fully control how a menu (or a different kind of 
user interface) should be displayed and provided, and style sheet support 
meets this requirement. Of course, Marco's idea about more scripting-based 
approach is also good, but I feel that this is rather overkill at the moment.

Regardless of whichever way we will select, the user must be able to control 
the appearance as much as possible arbitrarily and easily. Hiding a menu or 
putting a background image is just a part of this kind of framework, so they 
must not be implemented independently. Otherwise, we will have a pain of 
keeping backward compatibilty for such ad-hoc features.

Think about HTML and CSS. If HTML were designed only for implementing logical 
data at the beginning, browsers could have been much simpler and less 
bloated. HTML is so shabby, because it was not well designed. Browsers have 
to support CSS as well as legacy attributes, and HTML still contains some 
formatting information (such as the rendering effect of newline). All of 
these are causing a lot of problems indeed.

Okuji