New Boot Loader Menu

[Devin Teske]

On Oct 7, 2012, at 11:02 PM, Doug Barton wrote:

> On 10/07/2012 13:27, Devin Teske wrote:
>> 
>> On Oct 7, 2012, at 12:23 PM, Doug Barton wrote:
>> 
>> I reject your proposed hypothesis that this was my intent (the proper
>> intent is described below).
>> 
>> 
>>> "But that's not why I mentioned how many hours I spent." "So why
>>> mention it at all?" :)
>>> 
>> 
>> My precise intent for mentioning this was for the other Forth and/or
>> boot-menu folks (not the casual person).
>> 
>> I didn't want the other Forth hackers to get excited and perhaps form
>> the markedly false impressions that either:
>> 
>> b. that submenus were easy to add 
> 
> Right, you wanted us all to know how hard you worked.

Re-casting the same aspersions (but removing or changing context so that they look fresh) doesn't make them true, no matter how much you'd like them to be. I already explained (and you cut) the real impetus to my work.



> Congratulations,
> your efforts seem well received.
> 

Sarcasm. You've surely mastered this art. Recognize sir, that you are not the Lorax and thus you do not speak for the trees.



>>> Others have already brought up their favorite items to keep at the
>>> top level, I think it would be much simpler to leave everything
>>> that is at the top level now, and make submenus option number 8.
>> 
>> What name would you give this "all submenus" menu item? 
> 
> That works for me.
> 

Others have already come forth (no pun intended ^_^) and stated that this does not work for them. Let's talk alternatives.

I really like Alexander Leidinger's suggestions. ^_^



>> Because, as
>> previously discussed, if the menu stays as-is, we can really only
>> have one more item
> 
> You keep saying that your current code allows for 9. There are 7
> currently. Did I miss something?
> 

My code, sir (pay special attention to lines 436 and 437 -- especially 437 in the context of 436, in the further context of 430-434):

http://svnweb.freebsd.org/base/head/sys/boot/forth/menu.4th?revision=222417&view=markup

430		\ Note that any menu item beyond 9 will have a numerical prefix on the
431		\ screen consisting of the first digit (ie. 1 for the tenth menu item)
432		\ and the key required to activate that menu item will be the decimal
433		\ ASCII of 48 plus the menu item (ie. 58 for the tenth item, aka. `:')
434		\ which is misleading and not desirable.
435		\ 
436		\ Thus, we do not allow more than 8 configurable items on the menu
437		\ (with "Reboot" as the optional ninth and highest numbered item).

In addition, in this very thread, I've said:

From: http://lists.freebsd.org/pipermail/freebsd-arch/2012-October/013202.html

"Each submenu can have up to 9 maximum (tho we like to keep it at 8 for multiple reasons) menu items."

To explain further:

+ Yes, menus can have 9 items
+ No, they cannot have 9 **configurable** menu items
+ The 9th slot is for an optional built-in "Reboot" menu item

And furthermore:

A problem arises when:

a. $menu_options is set (injecting a "Options:" -- text configurable -- visible separator)
b. $menu_reboot is set (injecting the aforementioned "Reboot" built-in)
c. All 8 configurable menu items are configured

Then the menu area is too small (imho) to accommodate the menu because the 9th menu item then bumps up against the bottom border (largely because of the $menu_options separator which didn't exist when I originally designed the layout).



>> and so said-new-item would have to be an "all
>> submenus" option. Somehow, I don't think jpaetzel, avg, and mav are
>> going to like this as a solution for their proposed-new "BE menu"
>> (having "8. Submenus" -> "2. BE Submenu" -> "Select a BE" just seems
>> too deep-a-traversal).
> 
> Given how few people will be using anything other than what is at the
> top level, I doubt it. However, given that we can have 9 more menu items
> on the second page of menus,

8 really. The 9th item is not configurable (unless you ask very nicely and then I'll put the time and effort in to make-it-so).



> why not have a few of the more popular
> items at the top, and then more submenus below?

I really like the idea that Alexander Leidinger had, which was to move "Boot Single User Mode" up to the "actions section" of the main menu.

I slept on this and it has the very nice side-effect of changing the instructions for entering single-user mode _BACK_ to the way it was 16+ months ago _before_ the introduction of my stateful-menu.

In other words, moving "Boot Single User Mode" from a boolean option to an action item, the instructions for entering SUM change from (currently):

	Press 's' then 'ENTER'

back to the ol':

	Press 's'

Tho, unlike the old days, we retain the shiny ability to do things like verbose-SUM with these simple instructions:

	Press 'v' then 's'

(couldn't do things like that 16+ months ago with the old stateless-menu)



> That's what is going to
> happen on the first menu page, so the UI will be consistent.
> 
>>> Bonus points if you can make it easy to add a submenu via
>>> loader.conf.
>>> 
>> 
>> Done. There's zero difference in configuring menus in a "menu.rc"
>> file than in "loader.conf" file.
> 
> Ok, different file, same idea. Can you post some sample menu.rc code so
> we can get an idea of what "easy" means to you?
> 

Gladly! Thank you for asking!

I'll post the 4 different "menu.rc" files that I am planning on demonstrating this Thursday at BAFUG.

Please find attached the following files (with accompanying descriptions below):

menu.rc.1.current-head
This is what is in HEAD, CURRENT, and RELENG_9 **right now**

NOTE: Each of the following menu.rc examples *require* the new patchset that I'm sending through my mentor(s) to import to FreeBSD. We currently can't utilize _any_ of these features without the addition of "menusets.4th" (for example; among other changes).

menu.rc.2.submenu-head
This is the menu.rc file that replicates the images posted at the beginning of this thread.
Though, currently, I'm thinking I ought to craft a new menu.rc to show what Alexander Leidinger proposes.

menu.rc.3.submenu-cycler
This menu.rc shows things that DruidBSD offers (but FreeBSD cannot). In other words, don't get too exciting about the *actual* menu items, get more excited about "what the menu can do" by this example. This example goes to show that (if we need it), we can accommodate "cycling" menu items (where a single menu item on a single stateful menu can exhibit a total of 10 usable states). These menu items "cycle" -- meaning when you reach the last configured item, it cycles back to the first. The text for these cyclic menu items (just like toggle menu items) are completely arbitrary (explaining that the "1of2" and "2of2" etc. text is configurable).

NOTE: The next example consists of two files. The menu.rc _and_ a very small devicemenu.4th file which serves as a stand-in for C callbacks. In other words, the code that is in the accompanying "devicemenu.4th" is actually mimicking what *ought* to instead be a series of C callbacks exposed to the FICL layer from something like base/head/sys/boot/ficl/loader.c

menu.rc.4.submenu-dynamic
devicemenu.4th

This menu.rc shows how you can configure a menu that has not only dynamic menu *items* but that whole menus can be dynamic themselves (the menu items themselves are dynamically generated at runtime).

To make a dynamic menu, you have to back it by some runtime code. In this example, I've backed the callbacks with Forth code, but ***you don't have to*** and in-fact, my plans are to have these callbacks instead be provided by the POSIX C layer, namely base/head/sys/boot/ficl/loader.c (as one place where the C code exposes FICL constructs -- which ultimately are to be passed into the menu as a callback, configured via appropriately-named environment variables).

What's imperative to see in the demo of these 4 menu.rc files is that no Forth needs to be changed. Just drop in the appropriate menu.rc and reboot (SEE BELOW WARNING!)

WARNING!!! as previously explained,… you _MUST_ have the patches that I sent to avg and mav to be able to "just drop in these menu.rc files and reboot" -- if you drop anything but the HEAD menu.rc into a HEAD copy of /boot … you… will… not… boot… !!!

For a copy of what I sent to avg and mav, check out my twitter account or drop me a line.


>>> Regarding the UI on your submenu example; never, ever, ever use 
>>> Backspace to mean anything other than "delete the character behind
>>> the cursor."
>> 
>> Seriously? Who made _that_ rule? and moreover, _WHY_?
> 
> Um, if you don't already know the answers, I really can't help you.

Ok, so you're no chaplain. I get that.


> Go
> get a book on how to right proper user interfaces.
> 

Great men have often told me:
The most influential thing you can do in another's life is often to…

… recommand a book …

Think about that (and let's ignore the fact that you assume I have read no books on UI design).

Truth be told, I read the *best* book on UI design. Apple's historical/old HIG. And if you laugh at that, I ask you … what other 700+ page book on UI design is more comprehensive? I don't know if the current HIG is 700+ pages (in fact, I think they reduced the size when they jumped to OS X and have since 1998 been reducing the size), BUT... when I read the HIG (front-to-back) in the late-80's/early-90's … it was a *compendium* that could give your foot a riotous-pain if you dropped it from a short height on one's unshielded hoof.

Backspace *IS* less than ideal, but you neither produced any arguments, nor did you place yourself on any grounds that would take you seriously. Nonetheless, I will take you seriously.

I will admit that keyboards (and their manufacturers) are the culprit that drives this need to stay away from "Backspace." Some keyboards physically say "Delete" instead of "Backspace". Therefore, presenting a UI that says "Backspace" might confuse people when (say) they have an Apple English US keyboard that has no "Backspace" (but instead a "Delete").

You'll also get zero argument out of me that putting "Delete" on-screen is not only to-be-avoided for the opposing situation (that some keyboards may not have a "Delete" but instead "Backspace") but indeed "Delete" is worse because the implied connotation associated with the "Delete" key (_someone_ might be confused into thinking "Delete" will purge the menu from memory).

I will play with keycodes.

Just be aware that currently left arrow CANNOT work. That is a bad suggestion (read why below).

In Forth, I'm using the "key" primitive which -- rather unfortunately -- produces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arrow", "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: it doesn't catch "F11", "F12", "F13", "F14", "F15", or "F16").

So all those key options are right-out when it comes to "using them instead of Backspace" (I simply can't identify in the loader when those keys are pressed).



> Meanwhile, I've no objection to the idea of having move "safe mode" to a
> submenu, if that's the consensus. I don't think we should move ACPI
> because users who need to enable that option are already having enough
> problems as it is.
> 

Alexander Leidinger suggested (paraphrasing):

1. Boot
2. Escape to prompt
3. Reboot
4. Boot Single-User
(separator)
5. Boot options
6. Root device (future)

Sounds like you're suggesting:

1. Boot
2. Escape to prompt
3. Reboot
(separator)
4. ACPI Mode
5. Boot Single User
6. Boot options
7. Root device (future)

When I think about what you said (ACPI being used often), I question…

Are there really people that need to be fiddling with this option on a per-boot basis
_OR_
are these people simply going into loader.conf(5) and making a permanent selection if-and-when they have a problem?

thoughts?
-- 
Devin

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