[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Suggestion] LILO-like direct menu item access && scripting

From: Marco Gerards
Subject: Re: [Suggestion] LILO-like direct menu item access && scripting
Date: Tue, 08 Feb 2005 21:48:43 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Marc-Jano Knopp <address@hidden> writes:

> On Mon, 07 Feb 2005 at 17:33 (+0000), Marco Gerards wrote:
>> Serbinenko Vladimir <address@hidden> writes:
>> > Not at all because this syntax will mean that key is executed
>> > before choosing entry that I don't like. I propose the following
>> > syntaxes (I'm waiting for your suggestions which to use):
>> In that case you just should not press that key. :)
>> There is only the problem of key collisions (c is used for the
>> console, for example).  Perhaps 0-9, c-a and c-z can be used or so, I
>> personally don't care too much about this.
> Strange, both of you don't seem to like the idea of a menu mode, and
> rather accept restrictions in the choice of menu item letters. I would
> rather install Windows than accept such an inconsistency or restriction.

The other keys have a meaning already and because of that those keys
can not be used.  But what do you mean with menu mode?  I did not say
in my email that I did not like the idea, right, so what makes you
think that.

> Though I'm out of time for doing this myself, it doesn't seem too
> difficult to introduce a menu mode in GRUB: a flag, e.g.
> lilo_menu_mode and possibly a single if-statement to choose between
> the two command parsers and/or tables.

Why two menus if the main menu can get hotkey support?

> Or am I too optimistic?
> As I mentioned before, there should be a way to absolutely (not
> relatively) select this LILO menu mode, so that you can really blindly
> work with it. So a toggle-menu-mode command/key (alone) will not
> suffice, there should be two different commands/keys for selecting
> the native GRUB command mode and the LILO menu mode.

Ehm.  You are changing your ideas now.  In the previous email you
described something to bind a key to a menu item, now you are talking
about a new menu?

> Of course, the lilo menu behavior is also possible without an extra
> mode, but then you have use Ctrl/Alt/whatever for either the GRUB
> commands or the LILO selection, and in both cases it's unnecessarily
> cumbersome (especially, if a menu item could be selected by a whole
> /string/, not a just a single letter/cipher).

Using a whole string seems silly to me as well. :)

> If you insist on modeless operation (oh, c'mon! :-}, please us Alt
> instead of Ctrl; it's much easier to use, as the left thumb isn't
> used elsewhere (the space bar can be operated with the right thumb
> as well) - as opposed to the left pinky. :-)

Have you thought about how to implement that as well? :)

This will be quite hard.  When reading a key you just know about
ctrl.  Reading alt sucks, especially for portability.
>> But it would be nice, IMHO, if it was clear which entry has which
>> hotkey.  Perhaps the title can be followed by the key in some
>> different color or so?
> Hmm... I think the other way round would be nicer, as that's the
> usual way to do it (and everything is naturally aligned nicely then).
> (I think in LILO menus the order is the same, i.e. first letters, then
> name of the menu item).

The other way around?  Can you describe that please?

> Hmm... you mean every item has an implicit, automatically generated
> hotkey unless the user defines hotkeys of his own? Well, as long as
> it's printed somewhere, why not. But I think that there should be a
> way to undefine these automatically given hotkeys for each menu item
> then - at least I would like to be able to do so, as otherwise I'd
> feel like losing control a little, and then I could also install
> Windows. :-)

It seems you really are looking for reasons to install windows, no?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]