Re: Ideas for the future

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

(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
>> consistent.
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
>> 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 { ... }
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.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko