grub-devel
[Top][All Lists]
Advanced

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

Re: Ideas for the future


From: Andreas Vogel
Subject: Re: Ideas for the future
Date: Mon, 05 Mar 2012 12:16:36 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

Am 05.03.2012 02:30, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> this works already. For submenus this doesn't work as the submenu
>> entries are not re-evaluated after execution of it's menuentries.
>> Example:
>>      set lang=us
>>      menuentry 'Boot with lang=$lang' { ... ; linux lang=$lang ; boot }
>>      submenu Settings {
>>          submenu 'Language... (current lang = $lang)' {
>>              menuentry --silent=1 'Set lang US'  { set lang=us }
>>              menuentry --silent=1 'Set lang DE'  { set lang=de }
>>          }
>>      }
> 1) Environment variable substitution in menus. For normal menu entries
> Have you seen the argument possibility?
Yes, I know about it. But that doesn't help because the submenu
definition is read only once, so after that initial read the title is
and remains static text.


>> 2) Environment variable substitutions in theme labels. Theme labels
>> should be able to reference environment variables for display. It
>> would/could be even great to use environment variables for different
>> things in themes (fonts, pictures, etc...).
> That seems pretty vague do you have an idea in mind?
Sure. I wanna be able to display labels in the theme which shows the
current language, keyboard and other parameters which are used to boot
the linux kernel and which can be set in the settings submenu. All those
settings are environment variables, but right now there is no way to use
them in themes.


>>   By this it would be possible
>> to use a quite generic theme.txt file for different resolutions, etc.
> This is already possible. Use percent notation for desired size and
> rendering will figure out the actual size basing on constraints.
I know about that, but that's not the point.
I have smth in mind like:

set myfont="Fixed Regular 10"
if [ "$gfxmode" = "800x600" ] ; then set myfont="Fixed Regular 12" ; fi
if [ "$gfxmode" = "1280x1024" ] ; then set myfont="Fixed Regular 14" ; fi

and in the theme

+ boot_menu {
    item_font = "$myfont"
}

This is just an example. We could use it for almost everything in the
theme: background pictures, colors, fonts, text, etc. E.g., why do i
need to have 2 different theme.txt files when i just wanna have a
different desktop image?

BTW, another point which might be addressed in the future: the global
theme properties like "desktop-image" or "title-text" use minus char
between words, all other properties are using underline. Not really
consistent.


>
>> 3) Enhanced hotkey handling: support ALT, SHIFT and CTRL modifiers.
>>
>> 4) menuentry/submenu --hidden 0|1
> We don't use 0|1. We just make it argumentless and option toggles the
> behaviour
I know. But there is a slight advantage using a boolean argument for
such commands: it's a little nicer to deal with them when using variables.
E.g.:

    if [ "feature" = unavail ] ; then
        set hidden=1
    else
        set hidden=0
    fi
    menuentry "Boot memtest86" --hidden $hidden { ... }

for looks nicer opposed to

    if [ "feature" = unavail ] ; then
        set hidden="--hidden"
    else
        set hidden=
    fi
    menuentry "Boot memtest86" $hidden { ... }

When i implemented my patches, i wanted to use both ways: a command line
option with an optional argument. By this we would have had what you
preference and my way too. Regarding optional arguments the option
handling in GRUB is actually broken by design, so this is,
unfortunately, not an option.

The reason for why i say that optional argument parsing is broken by
design is because of that:
Let's assume the menuentry command.
When I define an additional option -s | --silent taking an optional
integer argument, then calling

    menuentry title --silent { echo OK }

gives an error "--silent requires an integer". This is because the
option parsing code handles the "{ ... }" as the value to the option
--silent.
The only way to prevent this (not acceptable IMO) is to call

    menuentry title --silent -- { echo OK }


>> Hidden menuentries behave the same like normal menu entries but they are
>> not visible on the screen. They can only be activated using a hotkey. By
>> this you can define a help screen using hotkey F1 but no visible menu
>> entry is needed.
> The problem is that such entries are not usable if the hotkey in
> question is unavailable because of terminal limitations.
Don't really understand your argument. Of course you'll have problems if
you use a key which is not available on your keyboard. For my example
implementing a help screen which is shown by pressing F1 you can use
another hotkey, e.g. <CTRL>-h.
I don't really see the point against having hidden menuentries,
especially when taking into account that i provided a real life example.


>> 5) menuentry --silent 0|1
>> When using menuentries which just sets some variables or do some other
>> (non booting tasks), it's really bothering to see a flickering empty
>> terminal box just for nothing. When this flag is set, the terminal box
>> will not be shown by default when the entry is executed. Execution of
>> submenus should be always silent.
> Rather than removing messages better move them to some status bar in
> the theme.
You didn't get the point. Why should any terminal box open when there is
nothing to display? When there are errors, the terminal box will open
anyway.
What bothers me (and btw. a quite some others) is that when you have
such a menu entry
    menuentry 'Set language to US' { set lang=us }
and when executing this entry an empty terminal box will be shown for a
very short time (opened and closed). It's just flickering, totally
useless and bothering, not nice.


>> 6) menuentry --enabled 0|1
>> It's a good practice to show menuentries even if they are not applicable
>> in different situations (that's common for all major menu systems). If a
>> menu entry is disabled, it is shown but it is not operable. E.g. one
>> might have a general grub config file which supports booting a bunch of
>> ISO images. When an ISO image is not found and instead of not showing a
>> menuentry for that, those menuentry could be shown as disabled.
> This seems like just cluttering the view. Remember that in some
> applications (e.g. braille) menu has to be very concise. We support
> even the tiny (40x1) terminal geometries.
Not at all. Every decent menu system supports disabled menu entries and
serious design guides suggest better to have disabled menu entries than
not to show them at all. If you have a look in Firefox, Thunderbird
(just to mention 2 programs), you'll see  that they all use disabled
menu entries.
Btw, I don't really understand your point about braille displays: a
disabled menu entry would look almost the same like an enabled one.


Andreas




reply via email to

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