Date: Sun, 7 Oct 2012 13:27:08 -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: <B4A82131-4B11-4FE8-839B-FCC45C1D4445@fisglobal.com> In-Reply-To: <5071D6B5.1010609@FreeBSD.org> References: <0655B56F-AD43-402B-872C-568378E650F9@fisglobal.com> <5071D6B5.1010609@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 7, 2012, at 12:23 PM, Doug Barton wrote: > On 10/06/2012 16:48, Devin Teske wrote: >=20 >> NOTE: This change is not trivial. It took me nearly a month of >> hacking to produce this _and_ almost 1,000 changed lines of code are >> required. >=20 > It's generally a good idea to ask for feedback before spending this > amount of time on something. I will agree that _generally_ it's a good idea, but in my case feedback mak= es no difference with respect to how much effort I put into something like = this. The reason being that these features, if not taken into FreeBSD, will simpl= y live on happily in DruidBSD. The boot loader menu that is currently used in FreeBSD HEAD, CURRENT, and R= ELENG_9 in-fact was used in DruidBSD for nearly 7 years before it was impor= ted to FreeBSD. > Coming to the community and saying, "I > spent so much time on this, you have to accept it" doesn't fly. >=20 I reject your proposed hypothesis that this was my intent (the proper inten= t is described below). > "But that's not why I mentioned how many hours I spent." > "So why mention it at all?" :) >=20 My precise intent for mentioning this was for the other Forth and/or boot-m= enu folks (not the casual person). I didn't want the other Forth hackers to get excited and perhaps form the m= arkedly false impressions that either: a. the current code allows for submenus b. that submenus were easy to add c. that shoving the boot options into a submenu is something that can be do= ne with a "1 line commit" Rather, I sought to set the stage that if the proposed "end result" is desi= rable, it would give me impetus to continue working in that direction (whic= h is a tiny fork in the end of a long road of committing ~1000 lines of req= uisite enhancements). By providing the information I did at the end, I was not stating "I worked = hard on this, you must accept it," but rather I was stating "here's somethi= ng nice, if you want it I'm prepared to make it happen and this is what you= can expect to be committed as-described by said effort." I did not perceive that anybody would construe my statement-of-effort as an= ything other than being totally up-front about what went into the final pro= posed-product versus trying to be sneaky and pull a "bait and switch" (some= thing I definitely would have perceived if somebody _didn't_ itemize the ef= fort that went into something that *looked* simple or *sounded* easy). >> Features such as submenus, dynamic menus and menu items, >> and more were added and I'm at a point where I can commit this back >> to the tree. I'm sure we want these features, but we have a choice of >> keeping the menu as-is without any changes _or_ we can choose to use >> the new features (as exhibited in this proposal -- where the boot >> options are sidled-off into a submenu). >=20 > 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? Because, as previou= sly discussed, if the menu stays as-is, we can really only have one more it= em 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). > Bonus points if > you can make it easy to add a submenu via loader.conf. >=20 Done. There's zero difference in configuring menus in a "menu.rc" file than= in "loader.conf" file. Menus (and submenus alike) are configured via appropriately named environme= nt variables. How these environment variables get set is entirely up to the= clients of my framework. You can set them via menu.rc, loader.conf, in the= C layer (e.g., sys/boot/ficl/loader.c), or the Forth layer. It makes no di= fference. However, I implore everybody to stay away from the Forth layer be= cause adding massive amounts of static text to that layer can *quickly* cau= se dictionary overflow which leads to immediate and fatal BTX halt. Setting= the environment variables in menu.rc, loader.conf, or the C layer doesn't = suffer from the limitations of the FICL dictionary size (and bumping the di= ctionary size is not always the right solution). > 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_? My reasoning=85 you want to be able to account for non-responsive systems i= n which case the user jams on a given key because they don't get a screen-u= pdate right-away. In this case, what's the harm in jamming on Backspace? Ev= en if they somehow drop to an interactive prompt and are still jamming Back= space, what's the harm? I don't understand this out-of-the-blue axiom. Can you or someone explain its origins and or enlighten me to the edge-case= that led to its creation? I'l in-turn become one a staunch follower, I jus= t want to know the pathos behind it. > Unfortunately you cannot use 'B' or Escape here either since > they have meaning in the previous menu. Right-o > 'Left Arrow' is likely the best > choice, although Home or even 'Page Up' would be better than Backspace. >=20 Hmmm, I find myself wishing that there could be multiple keycodes associate= d with a given menuitem, but at this time there's really only one keycode t= hat can be set (without further enhancement). I'll try playing around, but I'm afraid that backspace just felt so "right"= that my hands won't want to do anything else. I can tell you from playing around with submenus for quite awhile, that it'= s sometimes annoying (until you get the repetition down) having to hunt for= the key to "take me back" (and backspace just seemed "right" as the key to= "take me back" no matter where I am). It also seemed to play well because = I was logically perceiving a traversal to the right into the submenu, and (= perhaps this is strictly because I am a native English speaker that types l= eft-to-right), backspace was the logical correct thing to take me back "to = the left" just as it does when typing. --=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?B4A82131-4B11-4FE8-839B-FCC45C1D4445>