pretty colors in gfxterm

pretty colors in gfxterm

[Robert Millan]

Hi,

Is it possible to archieve a similar effect to what "color cyan/blue white/blue"
does in grub legacy, but with grub2 gfxterm?

This setup has been the default in debian for a while, and we need to provide
something similar if we don't want our users to miss the "blue thingy" during
the big migration we're planning.

Ah yes, I forgot to mention we're planning a big migration :-).  Here are the
details:

  http://wiki.debian.org/GrubTransition

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: pretty colors in gfxterm

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

Hi Robert,

> Is it possible to archieve a similar effect to what "color cyan/blue white/blue"
> does in grub legacy, but with grub2 gfxterm?

You could implement a color command, which does the same as the color
command in GRUB Legacy.  All terminals have support for the color
command.  Although I am not really sure if it is completely compatible
with what you are used to.

Although, it would be better to implement what Okuji proposed a while
ago.  Are you willing to work on this?  It might be fun to do so :-).

> This setup has been the default in debian for a while, and we need to provide
> something similar if we don't want our users to miss the "blue thingy" during
> the big migration we're planning.
>
> Ah yes, I forgot to mention we're planning a big migration :-).  Here are the
> details:
>
>   http://wiki.debian.org/GrubTransition

If having a color command means that GRUB 2 will be used more, I am
willing to add such command.  Okuji, do you object?  But I am only
willing to add this if the Debian people ensure me that they will
switch to whatever fancy graphics system we implement in the future,
when it is ready ;-).

--
Marco

Re: pretty colors in gfxterm

[Robert Millan]

On Sat, May 05, 2007 at 06:36:03PM +0200, Marco Gerards wrote:
> Robert Millan <rmh@aybabtu.com> writes:
> 
> Hi Robert,
> 
> > Is it possible to archieve a similar effect to what "color cyan/blue white/blue"
> > does in grub legacy, but with grub2 gfxterm?
> 
> You could implement a color command, which does the same as the color
> command in GRUB Legacy.  All terminals have support for the color
> command.  Although I am not really sure if it is completely compatible
> with what you are used to.

Can you give some pointer to that?

> Although, it would be better to implement what Okuji proposed a while
> ago.  Are you willing to work on this?  It might be fun to do so :-).

Willing yes, capable not.  Lacking time and skill.  Skill can still improve,
but time.... :-/

> If having a color command means that GRUB 2 will be used more, I am
> willing to add such command.  Okuji, do you object?

Yes, I think so.  But as said on IRC, I don't think the interface has to be
a color command.  As long as we can display something that is not uglier
than "color cyan/blue white/blue" (and we don't have to wait ages untill the
new fancy menu is ready), that's ok.

> But I am only
> willing to add this if the Debian people ensure me that they will
> switch to whatever fancy graphics system we implement in the future,
> when it is ready ;-).

I'm all for that, at least in desktops.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: pretty colors in gfxterm

[Yoshinori K. Okuji]

On Saturday 05 May 2007 18:49, Robert Millan wrote:
> > You could implement a color command, which does the same as the color
> > command in GRUB Legacy.  All terminals have support for the color
> > command.  Although I am not really sure if it is completely compatible
> > with what you are used to.
>
> Can you give some pointer to that?

Basically, you only need to call setcolor on a terminal. It should just work 
fine.

> > Although, it would be better to implement what Okuji proposed a while
> > ago.  Are you willing to work on this?  It might be fun to do so :-).
>
> Willing yes, capable not.  Lacking time and skill.  Skill can still
> improve, but time.... :-/

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.

> > If having a color command means that GRUB 2 will be used more, I am
> > willing to add such command.  Okuji, do you object?
>
> Yes, I think so.  But as said on IRC, I don't think the interface has to be
> a color command.  As long as we can display something that is not uglier
> than "color cyan/blue white/blue" (and we don't have to wait ages untill
> the new fancy menu is ready), that's ok.

It is strange to me that you think white/black is ugly. For me, this looks so 
good. :p

Okuji

Re: pretty colors in gfxterm

[Robert Millan]

On Mon, May 07, 2007 at 09:18:51PM +0200, Yoshinori K. Okuji wrote:
> > > If having a color command means that GRUB 2 will be used more, I am
> > > willing to add such command.  Okuji, do you object?
> >
> > Yes, I think so.  But as said on IRC, I don't think the interface has to be
> > a color command.  As long as we can display something that is not uglier
> > than "color cyan/blue white/blue" (and we don't have to wait ages untill
> > the new fancy menu is ready), that's ok.
> 
> It is strange to me that you think white/black is ugly. For me, this looks so 
> good. :p

It's green/black here (gfxterm), but still too bad for many users.  If it was
only for me, I couldn't care less.  But users do generaly care a lot about
aesthetics.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: pretty colors in gfxterm

[Robert Millan]

On Mon, May 07, 2007 at 09:18:51PM +0200, Yoshinori K. Okuji wrote:
> On Saturday 05 May 2007 18:49, Robert Millan wrote:
> > > You could implement a color command, which does the same as the color
> > > command in GRUB Legacy.  All terminals have support for the color
> > > command.  Although I am not really sure if it is completely compatible
> > > with what you are used to.
> >
> > Can you give some pointer to that?
> 
> Basically, you only need to call setcolor on a terminal. It should just work 
> fine.
> 
> > > Although, it would be better to implement what Okuji proposed a while
> > > ago.  Are you willing to work on this?  It might be fun to do so :-).
> >
> > Willing yes, capable not.  Lacking time and skill.  Skill can still
> > improve, but time.... :-/
> 
> 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.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: pretty colors in gfxterm

[Yoshinori K. Okuji]

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.

Okuji

Re: pretty colors in gfxterm

[Otavio Salvador]

"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?

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: pretty colors in gfxterm

[Yoshinori K. Okuji]

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

Re: pretty colors in gfxterm

[Otavio Salvador]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

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

Ok, I agree with you.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: pretty colors in gfxterm

[Robert Millan]

On Tue, May 08, 2007 at 10:09:49PM +0200, Yoshinori K. Okuji wrote:
> 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.

I tend to agree, but it doesn't necessarily have to be a "hiddenmenu" command.
It can be a "set hiddenmenu=1" variable, or whatever.  Is that what you meant?

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: pretty colors in gfxterm

[Otavio Salvador]

Marco Gerards <mgerards@xs4all.nl> writes:

> If having a color command means that GRUB 2 will be used more, I am
> willing to add such command.  Okuji, do you object?  But I am only
> willing to add this if the Debian people ensure me that they will
> switch to whatever fancy graphics system we implement in the future,
> when it is ready ;-).

It would be nice to preserve the current grub legacy look when
upgrading. Of course we'll use the new fancy graphics once done :-)

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: pretty colors in gfxterm

[Yoshinori K. Okuji]

On Saturday 05 May 2007 18:30, Robert Millan wrote:
> Is it possible to archieve a similar effect to what "color cyan/blue
> white/blue" does in grub legacy, but with grub2 gfxterm?

Theoretically, of course. I didn't implement it, simply because I didn't think 
this was so important.

> This setup has been the default in debian for a while, and we need to
> provide something similar if we don't want our users to miss the "blue
> thingy" during the big migration we're planning.
>
> Ah yes, I forgot to mention we're planning a big migration :-).  Here are
> the details:
>
>   http://wiki.debian.org/GrubTransition

I would say that this is still hard. Especially, I miss security-related 
features. They are easy to implement, but I postponed it, because I was 
planning to rewrite the menu code significantly. But I still don't get much 
time to perform this, and I have no idea on when I will be able to.

Besides that, it is really necessary to check what workarounds for buggy 
BIOSes are missing in GRUB 2. The current bootstrap code on PC is based on 
somewhere around GRUB 0.96, so it is a bit outdated.

Okuji

Re: pretty colors in gfxterm

[adrian15]

> Ah yes, I forgot to mention we're planning a big migration :-).  Here are
> the
> details:
>
>   http://wiki.debian.org/GrubTransition
>
> --
> Robert Millan

>
>CDROM support. Not really important since Debian isn't using GRUB for CD
>boot atm, but it might be an interesting option for lenny.
>
>    * 64-bit detection on x86: needed for multi-arch DVDs.

  In my opinnion Grub2 should be also used for cd boot. To boot from cd I
mean. This will make Grub2 the live cd standard boot loader and would
led us to find more bugs that only the ones that appear when you boot
from a hard disk.

  As long as I know Grub2 boot from a cd is not being developed yet (see
http://lists.gnu.org/archive/html/grub-devel/2007-04/msg00053.html )

  We will have to wait for it or code it. :)

adrian15

Re: pretty colors in gfxterm

[Marco Gerards]

"adrian15" <adrian15@raulete.net> writes:

>> Ah yes, I forgot to mention we're planning a big migration :-).  Here are
>> the
>> details:
>>
>>   http://wiki.debian.org/GrubTransition
>>
>> --
>> Robert Millan
>
>>
>>CDROM support. Not really important since Debian isn't using GRUB for CD
>>boot atm, but it might be an interesting option for lenny.
>>
>>    * 64-bit detection on x86: needed for multi-arch DVDs.
>
>   In my opinnion Grub2 should be also used for cd boot. To boot from cd I
> mean. This will make Grub2 the live cd standard boot loader and would
> led us to find more bugs that only the ones that appear when you boot
> from a hard disk.

Yeah.

>   As long as I know Grub2 boot from a cd is not being developed yet (see
> http://lists.gnu.org/archive/html/grub-devel/2007-04/msg00053.html )
>
>   We will have to wait for it or code it. :)

Isn't this part of the SoC project too?

--
Marco

Re: pretty colors in gfxterm

[Robert Millan]

On Mon, May 07, 2007 at 04:39:58PM +0200, adrian15 wrote:
> >
> >CDROM support. Not really important since Debian isn't using GRUB for CD
> >boot atm, but it might be an interesting option for lenny.
> >
> >    * 64-bit detection on x86: needed for multi-arch DVDs.
> 
>   In my opinnion Grub2 should be also used for cd boot. To boot from cd I
> mean. This will make Grub2 the live cd standard boot loader and would
> led us to find more bugs that only the ones that appear when you boot
> from a hard disk.
> 
>   As long as I know Grub2 boot from a cd is not being developed yet (see
> http://lists.gnu.org/archive/html/grub-devel/2007-04/msg00053.html )
> 
>   We will have to wait for it or code it. :)

A simpler solution that would be very useful for Debian is to support
building floppy images (seems to be broken atm).  Even if we can't access
the CD, floppy images can be used with El Torito emulation to provide rescue
CD images that give you a grub shell.

Do you have an idea on how to build these floppy images?  The instructions
about concatenating boot.img with core.img don't work here.

Btw, with grub legacy it was possible to generate these images without need
for root privileges.  We need that for grub2 too.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: pretty colors in gfxterm

[Yoshinori K. Okuji]

On Monday 07 May 2007 21:04, Robert Millan wrote:
> Do you have an idea on how to build these floppy images?  The instructions
> about concatenating boot.img with core.img don't work here.

Strange... it worked in the past, but doesn't now. There must be a bug.

Okuji

Re: pretty colors in gfxterm

[Yoshinori K. Okuji]

On Monday 07 May 2007 21:32, Yoshinori K. Okuji wrote:
> On Monday 07 May 2007 21:04, Robert Millan wrote:
> > Do you have an idea on how to build these floppy images?  The
> > instructions about concatenating boot.img with core.img don't work here.
>
> Strange... it worked in the past, but doesn't now. There must be a bug.

Ah, no. After I recompiled it from scratch, I can just create a floppy image:

$ cat boot.img core.img | dd of=foo.img seek=0 conv=notrunc

Okuji