Okuji wrote:
> At Mon, 22 Apr 2002 11:54:53 +0200 (MEST),
> Klaus Reichl wrote:
> > separator --solid # drawing a line like top and bottom
> > separator "Some Text" # show "Some Text" like in title but
> > # make it non-selectable
>
> I'm not very concerned about the syntax. Rather, about the user
> interface.
>
Perfectly right, the main thing is the proposed semantics at the right
hand side not the syntax at the left.
> For example, suppose this:
>
> TITLE1 <- this is the selected line
> SEPARATOR1
> TITLE2
> SEPARATOR2
> TITLE3
>
> If the user pushes the down key, which line should the selected line
> move to? "TITLE2" or "SEPARATOR1"?
Of course TITLE2
> If any separators should be
> skipped, it is possible that some lines can never be shown. For
> example, suppose that the maximum number of lines is 4 and your menu
> contains:
>
> TITLE1
> SEPARATOR1
> SEPARATOR2
> SEPARATOR3
> SEPARATOR4
> SEPARATOR5
> SEPARATOR6
> SEPARATOR7
> TITLE2
>
> Then you cannot see SEPARATOR4, never.
To some extend, people writing `menu.lst' are programmers, and I
consider your example a programming (at least conceptional) mistake.
If I've just 4 lines to display and want the user show more than 4
lines (the separators can be considered as comments for the end-user)
than there is something wrong in my design (maybe I'm somewhat
old-fashioned here but I don't view HTML which are not designed for
them on WAP-mobiles, and I'm not really keen on GIFs used as
separators for GRUB).
>
> If you want to see SEPARATOR4, one solution would be that the cursor
> moves line by line but you cannot "run" any separator (e.g. by the key
> `b').
>
> Another issue is whether GRUB should count separators as entries. For
> example, in this menu:
>
> TITLE1
> SEPARATOR1
> TITLE2
>
> should TITLE2 be assigned to 1 or 2?
TITLEs are selectable items where SEPARATORs are comments making the
live for people programming/using complex menus easier.
So: TITLE1 => 1
SEP1 just shown as a comment
TITLE2 => 2
>
> Anyway, the biggest issue is whether the cost-performance is good or
> not. Clearly, adding this feature would make the implementation of
> GRUB more complicated and possibly more buggy.
Okuji is right, whether or not this is a hint at my implementation of
dumb terminals, which made the code more complicated and (blame me)
more buggy. But I still think, that people doing nothing don't do any
mistakes, and I'm happy to have those free software projects where
things are tried without fear of bugs, the bugs being fixed, or the
prototypes just thrown away if it turns out, that they are to complex.
BTW: I do have fixes for the dumb terminal support (see BUGS), and
planned to post them tonite, however, my new VMware test bench for
GRUB made troubles, so next time...
K
--
Klaus Reichl email: [EMAIL PROTECTED], [EMAIL PROTECTED]
_______________________________________________
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
