On Tuesday 08 May 2007 22:19, Otavio Salvador wrote: > "Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > > On Tuesday 08 May 2007 15:36, Robert Millan wrote: > >> > I don't have much time, either, but I will refactor the menu code > >> > sooner or later. Once this is done, it wouldn't be too difficult to > >> > implement new intefaces for the menu. > >> > >> Other (perhaps easier) options that would also improve the situation are > >> "hiddenmenu" and splash image support. > > > > I don't want to have ad-hoc features in GRUB 2. I have studied that > > ad-hoc harms. > > Sorry but I didn't get what you mean by 'ad-hoc features' here. Can > you elaborate it, please?
Features, which are not fully examined if they are generic, flexible and extensible, are all ad-hoc. As I said in this list some times, I believe that the user must be able to fully control how a menu (or a different kind of user interface) should be displayed and provided, and style sheet support meets this requirement. Of course, Marco's idea about more scripting-based approach is also good, but I feel that this is rather overkill at the moment. Regardless of whichever way we will select, the user must be able to control the appearance as much as possible arbitrarily and easily. Hiding a menu or putting a background image is just a part of this kind of framework, so they must not be implemented independently. Otherwise, we will have a pain of keeping backward compatibilty for such ad-hoc features. Think about HTML and CSS. If HTML were designed only for implementing logical data at the beginning, browsers could have been much simpler and less bloated. HTML is so shabby, because it was not well designed. Browsers have to support CSS as well as legacy attributes, and HTML still contains some formatting information (such as the rendering effect of newline). All of these are causing a lot of problems indeed. Okuji _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
