[Top][All Lists]

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

Re: Ideas for the future

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Ideas for the future
Date: Mon, 05 Mar 2012 13:54:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0

(CC'ing Colin because of theme stuff and it overlaps with what he needs for Ubuntu)
   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

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
That's unfortunate that noone noticed it when it was comitted but now we're stuck with it (compatibility)

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
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.

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

for looks nicer opposed to

     if [ "feature" = unavail ] ; then
         set hidden="--hidden"
         set hidden=
     menuentry "Boot memtest86" $hidden { ... }
I understand your point but consistency is more important.
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.
Again it's unfortunate that noone noticed it when it was committed and now we're stuck with it.

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.
If the option isn't hidden the unsupported hotkey is only a minor problem since you can still select the entry explicitly. As a compromise it may be possible to make it hidden only on gfxmenu while keeping it fully visible on normal menu renderer.

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?
I think you don't get mine: if this message goes to status bar it doesn't go to the terminal and so it doesn't open.

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.
Try living a day on 20x1 terminal and tell me what you think about all extra useless info you get.

Vladimir 'φ-coder/phcoder' Serbinenko

reply via email to

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