[RELEASE] New Boot-Loader Menu

Devin Teske dteske at vicor.com
Sun May 1 03:38:45 UTC 2011


On Apr 30, 2011, at 6:10 PM, Dieter BSD wrote:

>> Already on the to-do list is to support ``loader_logo=...'' in
>> /boot/loader.conf
> 
> Including an option for no logo? (For consoles that are slow and/or
> small, and for people that just don't like the logos.)

The current behavior -- with what's in CVS today -- is to draw a logo for all values of "loader_logo" except for "none".

My menu differs slightly, improving functionality by defaulting to not draw any logo for values we don't understand. Therefore "none" would have the desired effect (but so will "NO", "blank", "johnnycat", "billjoy", or even "" -- all produce a menu with no logo). NOTE: If NULL, we don't display the logo, however if unset, we'll default to displaying the chosen/sensible default (going for `orbbw' to comply with the aforementioned compatibility decrees -- of which I fully agree with). This is to facilitate the loader.conf(5) override ability.

Currently, you'd make the change by altering the ``set logo="orb"'' line in /etc/menu.rc (line 10). In the next release, I plan to change the environment variable from "logo" to "loader_logo" for backward compatibility (allowing loader.conf(5) override as previously mentioned).


> 
>>> Putting brackets around letters (and numbers) sounds good.
>>> If there is room, perhaps add a message explaining that
>>> the user should enter one of the choices in brackets.
>> 
>> I think I'm going to have to play with this and see what we come up with. I
>> don't want to make it too "busy" if you know what I mean. That's with
>> respect to the brackets. As for adding a messages... things are a bit tight
>> and again, I'm afraid of making it too cluttered. I'll post some screenshots
>> of some mock-ups tomorrow, incorporating the various requests.
>> 
>>> A help option would be useful, giving a reminder of what
>>> things like ACPI and APIC stand for, what "safe" mode does, etc.
>> 
>> This is not altogether infeasible. Since this menu (unlike the current one)
>> has the ability to be wiped from screen and then recalled completely in the
>> original state is was left in ... implementing an F1 feature that reads text
>> from a file would be very do-able.
> 
> If there is a help option that the user can figure out how to execute,
> the explaination about brackets (if you go that route), entering numbers,
> letters, and such could be included in the help screen(s) instead of the
> main menu page.

One of the decrees was that we shouldn't assume that there are function keys. I think that's a fair decree, so that puts me in a quandry with the "Press F1 for Help" model of presentation. Although convenient programmatically, it could potentially leave users without function-keys without an ability to read the carefully prepared messages awaiting their keypress.

There's really only room for one or two more menu items. Perhaps we could introduce a new menuitem after the reboot item. A menuitem whose number is perhaps not a number, but instead the question-mark. The text for which could be "[H]elp" (keeping to the recent bracketed concept -- which could conceptually switch to underline if loader_color is set).


> 
>>> Would be nice: a fix for having to lean on a key autorepeating
>>> for a couple seconds.
>> 
>> Could you explain? I don't follow.
> 
> On my Tyan Tomcat k8e 2865, just entering the number rarely if
> ever works. I have to either repeatedly bang away at the key or
> hold it down, letting the RS-232 terminal do the autorepeat thing,
> while hoping that it notices before the timer runs out.

Is that with the current code that's in CVS? I'd love for you to try my code on that hardware. One of the things that I worked on in the very beginning was the responsiveness.
-- 
Cheers,
Devin Teske


-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> FUN STUFF <-
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ L++++$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+
D+(++) G++ e>++++ h r+++ z+++
------END GEEK CODE BLOCK------
http://www.geekcode.com/

-> END TRANSMISSION <-

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________


More information about the freebsd-hackers mailing list