Syslinux - Oct 2020 - "Most Linux distributions won't be using "

> Thanks Gregory, my mistake, your explanation was half right and your code
was
> fully right, I meant to say the key is setting the first two digits in the
> foreground and background to "00" (which means transparent) this
will delete the
> color of the border, and then making the shadowing variable equal to
"none" this
> will delete the shadowing black line that appears by default. See this link
for
> the terminology:
https://wiki.syslinux.org/wiki/index.php?title=Menu#MENU_COLOR
> I am also looking to change the color of the text that is displayed in the
> syslinux boot menu when you press tab key, not the message ?Press [Tab] to
> edit options?, but the boot parameters text color (default is white font
with
> black shadowing) that?s displayed when tab key is pressed on main menu? I
> tried adding: menu msgcolor #90ffffff #80ffffff none  but the tab key
dependent
> text didn?t change. Do you know if there is a way to change the
vesamenu.c32
> code to change the text color of the tab key dependent text through this
> repository: https://git.kernel.org/pub/scm/boot/syslinux/syslinux.git/tree/
The
> file vesamenu.c (found in the com32/menu/ directory) seems to be the entry
point
> for changing the vesamenu.c32 build, but I couldn?t find any code in the
> vesamenu.c that deletes the menu border in syslinux(legacy boot), nor could
I
> find examples online?
> 
> Best Regards,
> 
> Nicholas Donald
 
 
Several points (please read the whole email before doing anything else):

1_ It is not clear whether you still need/want to "avoid displaying"
the menu
border (i.e. make it transparent). You mentioned that you eventually managed to 
do so, but then you also ask (again) about vesamenu.c regarding the menu 
border. Or, perhaps... Do you actually, really, want to "delete" the
menu
border (i.e. the menu border would _really_ be "zero pixels")? If
that's the
case, that's not available as a directive in syslinux.cfg, so you would need
to
hack the source code (and most probably you would be on your own at that).

2_ Regarding the color of the boot command (starting from the boot menu), the 
same link you posted also mentions other elements, such as "menu color
cmdmark"
and "menu color cmdline".

3_ Unless you specifically want to use a Syslinux variant (e.g. ISOLINUX), I 
would suggest not investing "too much" time on configuring it. In the
near
future, most Linux distributions won't be using it.

4_ If you still want to invest time on it, please carefully read the available 
documents, as most common answers are already there (e.g. "menu color 
cmdline").

5_ Please, avoid posting the same emails twice (relevant for any participant).

6_ When replying, please use the Syslinux Mailing List public email address, 
unless there is a specific reason not to do so (relevant for any participant).

7_ Please avoid top-posting; it is confusing, and annoying (relevant for any 
participant).

Regards,
Ady.

[ warning: thread hijack ]

On Tue, Oct 20, 2020 at 10:21:48PM +0300, Ady via Syslinux
wrote:
> ...
> 3_ Unless you specifically want to use a Syslinux variant (e.g. ISOLINUX),
I
> would suggest not investing "too much" time on configuring it. In
the near
> future, most Linux distributions won't be using it.
Can you explain/elaborate on what this means?

Sorry if I stripped too much context -- that wasn't my intention.

Thanks,
sr.

> > 3_ Unless you specifically want to use a Syslinux variant (e.g.
> > ISOLINUX), I would suggest not investing "too much" time on
> > configuring it. In the near future, most Linux distributions won't
be
> > using it.
> 
> Can you explain/elaborate on what this means?
 
 
It means that, in the near future, most _official_ ISO images of the 
most-popular Linux distributions won't be using ISOLINUX, but rather 
some other bootloader, or another method of distribution. This has 
already started to happen, and will be much more noticeable in the 
(very) near future.

Unfortunately, many auxiliary tools (e.g. Unetbootin, and many others) 
are currently not ready for such change. Generally speaking, I would 
suggest following each distro's instructions and support, instead of 
assuming that "some new ISO image fails to boot completely". I mean, 
the ISO images might fail, but in some cases such fail will depend on 
the method/tool in use. In many cases, _only_ a "dd-like" method 
is/will be officially supported by Linux distributions. Many auxiliary 
tools will need updates in order to work as expected. And, surely, some 
ISO images will be incompatible with some hardware/firmware.

Regards,
Ady.