[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pretty colors in gfxterm
From: |
Yoshinori K. Okuji |
Subject: |
Re: pretty colors in gfxterm |
Date: |
Thu, 10 May 2007 00:10:16 +0200 |
User-agent: |
KMail/1.9.4 |
On Tuesday 08 May 2007 22:19, Otavio Salvador wrote:
> "Yoshinori K. Okuji" <address@hidden> 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
- pretty colors in gfxterm, Robert Millan, 2007/05/05
- Re: pretty colors in gfxterm, Marco Gerards, 2007/05/05
- Re: pretty colors in gfxterm, Robert Millan, 2007/05/05
- Re: pretty colors in gfxterm, Yoshinori K. Okuji, 2007/05/07
- Re: pretty colors in gfxterm, Robert Millan, 2007/05/07
- Re: pretty colors in gfxterm, Robert Millan, 2007/05/08
- Re: pretty colors in gfxterm, Yoshinori K. Okuji, 2007/05/08
- Re: pretty colors in gfxterm, Otavio Salvador, 2007/05/08
- Re: pretty colors in gfxterm,
Yoshinori K. Okuji <=
- Re: pretty colors in gfxterm, Otavio Salvador, 2007/05/10
- Re: pretty colors in gfxterm, Robert Millan, 2007/05/09
Re: pretty colors in gfxterm, Otavio Salvador, 2007/05/05
Re: pretty colors in gfxterm, Yoshinori K. Okuji, 2007/05/07