Syslinux - Sep 2006 - Comments sought on the graphical menu infrastructure

Hi all,

I would really appreciate feedback on the graphical menu system and its 
infrastructure.  It's not really clear to me that it's what people want;
it seems to me that it makes more sense than gfxboot, for example (C 
rather than pseudo-Forth), but I can understand people would disagree.

Anyway, the more feedback I get the easier it will be to pick a 
direction and a priority for future work, so any comments are appreciated.

	-hpa

On 9/19/06, H. Peter Anvin <hpa at zytor.com>
wrote:
> Hi all,
>
> I would really appreciate feedback on the graphical menu system and its
> infrastructure.  It's not really clear to me that it's what people
want;
> it seems to me that it makes more sense than gfxboot, for example (C
> rather than pseudo-Forth), but I can understand people would disagree.
>
> Anyway, the more feedback I get the easier it will be to pick a
> direction and a priority for future work, so any comments are appreciated.
>
>         -hpa
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
Don't know how much my opinion counts for since I'm not actually a
developer.  However, I've been using Syslinux pretty much every since
I first realized that there was a positive benefit to using it on a
harddrive instead of just a CD.  Personally, I say that you've got the
right idea here with the new vesamenu.  You keep the basic
configuration file where all a user has to do is add a few things to
the configuration that make the menu work better -- but then even if
they don't the menu still functions.  Personally, right now I'm just
being lazy and using the vesamenu without changing the background or
anything yet (I'll get around to making a nice one sooner or later,)
but, I still like it a lot better since it's just plain easier on the
eye.

So far the only thing I've seen devs asking for is that they want to
be able to show their own logo (which you've definitely now covered)
and possibly some help text.  This too is covered by the ability to
position the menu differently (perhaps easier documentation covering
this so they can jump right in more easily -- a lot of things you have
to dig through the source or mailling lists to find syntax for, such
as the commands to move the menu itself around) so that you can
actually make an image with text.

IMO the most important thing is the simplicity.  Right now jumping
right on into using the simple menu (either menu.c32 or vesamenu.c32)
is as simple as running the appropriate module.  This makes it easy
for devs new to it to get started.  Right now the biggest problem
seems to be just making people realize that this new system will suit
their needs.  A lot of devs working on things that could benefit in
some small way from a nicer bootup (in particular I'm thinking of all
those working on live linux distros where -- especially in
troubleshooting -- the user is sometimes expected to pass rather a lot
of parameters at bootup and needs to know what those parameters are)
but don't quite realize it yet.

Anyway, like I said, I'm not an actual dev, so my opinion may or may
not actually be useful to you.

H. Peter Anvin wrote:
> I would really appreciate feedback on the graphical menu system and its 
> infrastructure.  It's not really clear to me that it's what people
want;
> it seems to me that it makes more sense than gfxboot, for example (C 
> rather than pseudo-Forth), but I can understand people would disagree.
> 
> Anyway, the more feedback I get the easier it will be to pick a 
> direction and a priority for future work, so any comments are appreciated.
I haven't yet tried configuring the menu, though I've already seen it in
action.

I'm wondering if there is some possibility of somehow doing an if/then
operation.

The idea would be that if VESA was set successfully, then a variable
could be passed to the Linux kernel stating that is the case.

I'm not sure of how useful that would be to others, but perhaps it could
detect broken VESA on cards before anyone tries to modprobe vesafb. Or
maybe ISOLINUX would crash equally nicely on these broken machines. I'm
not sure.

Just an idea.

--Pat

H. Peter Anvin a ?crit :
> Hi all,
>
> I would really appreciate feedback on the graphical menu system and its 
> infrastructure.  It's not really clear to me that it's what people
want;
> it seems to me that it makes more sense than gfxboot, for example (C 
> rather than pseudo-Forth), but I can understand people would disagree.
>
> Anyway, the more feedback I get the easier it will be to pick a 
> direction and a priority for future work, so any comments are appreciated.
>
> 	-hpa
>
>   
Hello,

Will it be hard to create some com32 drawing primitive functions for vesa ?
Like drawpixel, drawrect, drawfillrect ?

The goal for me is to create an advanced menu system with a graphical 
GUI instead of a text based one.
And maybe later mouse support ?

I was reading vesa specs for a moment now to try to add vesa mode to 
syslinux, but you've done it earlier... :)
Thank you for the great work.

-- 
Constantin Charissis
DATASWIFT

Ryan McLean wrote:
> Actually I would like to see the cfg file for the vesa menu seperated from 
> the current cfg file.
> 
> I use PXELinux and have alot of menu options (i have nearly all redhad 
> trees since version 3.0 for all Archs) so i have had to use multiple menu 
> files for those so updating to vesamenu means editing all my menu files 
> and proving options for it..
> 
> If you could add a parameter for the location of the gfx (so if not 
> defined, will 1st look in its cfg file if not there then uses defaults) 
> something like the syntax below:
> 
> KERNEL vesamenu.c32
> APPEND conf/x64-4.conf gfx/default.conf
> 
> Other than that looks really well good job.
> 
This is an excellent idea and, in fact, very easy to implement.  As a 
result I have implemented it and made it available as 3.31-pre1.  Please 
test it out and see if it does what you need.

	-hpa

I'd like to feedback the way we use syslinux/pxelinux. The graphical
menu is actually the right one we want. We use PXELinux in DRBL
(Diskless Remote Boot in Linux) project (http://drbl.sf.net), and it's
so nice we can show some nice background like this:
http://drbl.sourceforge.net/screenshot/?op=show&filepath=album//00_DRBL/drbl-pxe-vga-screenshot.png

It's so easy to use that, and people can easily change the background
by replacing a JPG or PNG file, that's fantastic!
-- 
Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org>
National Center for High-performance Computing, Taiwan.
http://www.nchc.org.tw
Public Key Server PGP Key ID: 9762755A

My files:

pxelinux.cfg/default:
--------------------------------
# Default boot option to use
DEFAULT vesamenu.c32

# Prompt user for selection
PROMPT 0

# Menu Configuration
MENU WIDTH 80
MENU MARGIN 10
MENU PASSWORDMARGIN 3
MENU ROWS 12
MENU TABMSGROW 18
MENU CMDLINEROW 18
MENU ENDROW 24
MENU PASSWORDROW 11
MENU TIMEOUTROW 20
MENU TITLE RHWS Main Menu


# Menus
LABEL x86-4
        MENU LABEL ^32Bit (x86) - 4.x
#       MENU HIDE
        KERNEL vesamenu.c32
        APPEND gfx/default conf/x86-4.conf
-----------------------------------------------------

conf/x86-4.conf
-----------------------------------------------------
# Default boot option to use
DEFAULT vesamenu.c32

# Prompt user for selection
PROMPT 0

# Time until default is selected
TIMEOUT 100

# Menu Configuration
MENU WIDTH 80
MENU MARGIN 10
MENU PASSWORDMARGIN 3
MENU ROWS 12
MENU TABMSGROW 18
MENU CMDLINEROW 18
MENU ENDROW 24
MENU PASSWORDROW 11
MENU TIMEOUTROW 20
MENU TITLE 32Bit (x86) RHWS 4.x OS Choice

# Return to Main Menu
LABEL MainMenu
        MENU DEFAULT
        MENU LABEL ^Main Menu
        KERNEL vesamenu.c32
        APPEND gfx/default
-----------------------------------------------------------

gfx/default
----------------------------------------------------------
# vesamenu Default cfg
#
# MENU BACKGROUND filename
MENU BACKGROUND back.jpg

# MENU COLOR element ansi foreground background

menu color screen               37;40      #80ffffff #00000000
menu color border               30;44      #40000000 #00000000
menu color title                        1;36;44    #c00090f0 #00000000
menu color unsel                37;44      #90ffffff #00000000
menu color hotkey               1;37;44    #ffffffff #00000000
menu color sel                  7;37;40    #e0000000 #20ff8000
menu color hotsel               1;7;37;40  #e0400000 #20ff8000
menu color scrollbar            30;44      #40000000 #00000000
menu color tabmsg               31;40      #90ffff00 #00000000
menu color cmdmark              1;36;40    #c000ffff #00000000
menu color cmdline              37;40      #c0ffffff #00000000
menu color pwdborder            30;47      #80ffffff #20ffffff
menu color pwdheader            31;47      #80ff8080 #20ffffff
menu color pwdentry             30;47      #80ffffff #20ffffff
menu color timeout_msg  37;40      #80ffffff #00000000
menu color timeout              1;37;40    #c0ffffff #00000000

----------------------------------------------------------------------------------

Unexpected behaviour:

1. My main menu has no background ( the bg it has i assume is a built in 
default)
2. On switching from my 2nd menu back to the main menu i get a black 
screen with the prompt "boot:"  pressing enter clears this and
displays my
main menu as above (ie no custom bg just defaults)
3. If i edit the APPEND line in conf/x86-4.conf that returns me to my main 
menu to "APPEND gfx/default pxelinux.cfg/default" it works.

Other than the above seems to work fine (only been playing with it for 
15min so may be more to come.. hopefully not though)

May I suggest the following as poss solutions:
1. Where we declare we want to use vesamenu at the top of each cfg file we 
pass the "default" gfx cfg file we want to use there.. "DEFAULT 
vesamenu.c32 gfx/default"
2. We have a fixed file location like pxelinux, if there is a folder 
called gfx it will use the file there called default if present and then 
additional/other files are declared inline as they are at present
3. A constant is added to the top of each file #!cfg or #!gfx and 
depending which is present then the file is either menu items or gfx 
configuration

Appoligies if I seem blunt above but just wanted to list what I viewed as 
unexpected in a simple and direct way.
I truely am grateful that you have begun to implement this as it will save 
me (and alot of other people) lots of work for simple changes.

Regards,


Ryan McLean