Date: Mon, 8 Oct 2012 10:21:34 -0700 From: Devin Teske <devin.teske@fisglobal.com> To: Doug Barton <dougb@FreeBSD.org> Cc: Devin Teske <dteske@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: New Boot Loader Menu Message-ID: <D776ABE7-6C46-4C66-8C6E-159BCD61761F@fisglobal.com> In-Reply-To: <50726C73.10506@FreeBSD.org> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org> <B4A82131-4B11-4FE8-839B-FCC45C1D4445@fisglobal.com> <50726C73.10506@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 7, 2012, at 11:02 PM, Doug Barton wrote: > On 10/07/2012 13:27, Devin Teske wrote: >>=20 >> On Oct 7, 2012, at 12:23 PM, Doug Barton wrote: >>=20 >> I reject your proposed hypothesis that this was my intent (the proper >> intent is described below). >>=20 >>=20 >>> "But that's not why I mentioned how many hours I spent." "So why >>> mention it at all?" :) >>>=20 >>=20 >> My precise intent for mentioning this was for the other Forth and/or >> boot-menu folks (not the casual person). >>=20 >> I didn't want the other Forth hackers to get excited and perhaps form >> the markedly false impressions that either: >>=20 >> b. that submenus were easy to add=20 >=20 > Right, you wanted us all to know how hard you worked. Re-casting the same aspersions (but removing or changing context so that th= ey look fresh) doesn't make them true, no matter how much you'd like them t= o be. I already explained (and you cut) the real impetus to my work. > Congratulations, > your efforts seem well received. >=20 Sarcasm. You've surely mastered this art. Recognize sir, that you are not t= he 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. >>=20 >> What name would you give this "all submenus" menu item?=20 >=20 > That works for me. >=20 Others have already come forth (no pun intended ^_^) and stated that this d= oes 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 >=20 > You keep saying that your current code allows for 9. There are 7 > currently. Did I miss something? >=20 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=3D2224= 17&view=3Dmarkup 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 \=20 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.h= tml "Each submenu can have up to 9 maximum (tho we like to keep it at 8 for mul= tiple 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 -- vis= ible 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 t= he $menu_options separator which didn't exist when I originally designed th= e 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). >=20 > 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 "Boo= t 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 instru= ctions for entering single-user mode _BACK_ to the way it was 16+ months ag= o _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 ver= bose-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. >=20 >>> Bonus points if you can make it easy to add a submenu via >>> loader.conf. >>>=20 >>=20 >> Done. There's zero difference in configuring menus in a "menu.rc" >> file than in "loader.conf" file. >=20 > 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? >=20 Gladly! Thank you for asking! I'll post the 4 different "menu.rc" files that I am planning on demonstrati= ng this Thursday at BAFUG. Please find attached the following files (with accompanying descriptions be= low): 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 tha= t 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" (fo= r 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 oth= er words, don't get too exciting about the *actual* menu items, get more ex= cited about "what the menu can do" by this example. This example goes to sh= ow that (if we need it), we can accommodate "cycling" menu items (where a s= ingle 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 config= ured item, it cycles back to the first. The text for these cyclic menu item= s (just like toggle menu items) are completely arbitrary (explaining that t= he "1of2" and "2of2" etc. text is configurable). NOTE: The next example consists of two files. The menu.rc _and_ a very smal= l 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 mi= micking what *ought* to instead be a series of C callbacks exposed to the F= ICL 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 m= enu *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 e= xample, 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 b= y 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 pass= ed into the menu as a callback, configured via appropriately-named environm= ent variables). What's imperative to see in the demo of these 4 menu.rc files is that no Fo= rth needs to be changed. Just drop in the appropriate menu.rc and reboot (S= EE BELOW WARNING!) WARNING!!! as previously explained,=85 you _MUST_ have the patches that I s= ent to avg and mav to be able to "just drop in these menu.rc files and rebo= ot" -- if you drop anything but the HEAD menu.rc into a HEAD copy of /boot = =85 you=85 will=85 not=85 boot=85 !!! For a copy of what I sent to avg and mav, check out my twitter account or d= rop me a line. >>> Regarding the UI on your submenu example; never, ever, ever use=20 >>> Backspace to mean anything other than "delete the character behind >>> the cursor." >>=20 >> Seriously? Who made _that_ rule? and moreover, _WHY_? >=20 > 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. >=20 Great men have often told me: The most influential thing you can do in another's life is often to=85 =85 recommand a book =85 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 =85 what other 700+ page book on U= I design is more comprehensive? I don't know if the current HIG is 700+ pag= es (in fact, I think they reduced the size when they jumped to OS X and hav= e since 1998 been reducing the size), BUT... when I read the HIG (front-to-= back) in the late-80's/early-90's =85 it was a *compendium* that could give= your foot a riotous-pain if you dropped it from a short height on one's un= shielded 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. Nonet= heless, 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 s= ay "Delete" instead of "Backspace". Therefore, presenting a UI that says "B= ackspace" might confuse people when (say) they have an Apple English US key= board 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 b= ecause 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 suggesti= on (read why below). In Forth, I'm using the "key" primitive which -- rather unfortunately -- pr= oduces a zero for "left-arrow", "right-arrow", "up-arrow", "down-arrow", "F= 1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", and "F10" (note: it doe= sn'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 p= ressed). > 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. >=20 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=85 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 se= lection if-and-when they have a problem? thoughts? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D776ABE7-6C46-4C66-8C6E-159BCD61761F>