On Mon, Sep 14, 2009 at 5:56 PM, Michal Suchanek <hramr...@centrum.cz> wrote:
> 2009/9/14 Bean <bean12...@gmail.com>:
>>Hi,
>>
>>Thanks a lot for your advice, most of them looks good, although some
>>details may need adjustment.
>
> Thank you for working on the new menu system.
>
> Of course, this discussion is here to select the best ways to
> implement the menu we can think of and refine them so that we can save
> work on (re-)implementation and maintenance.
>
>>
>> About edit boxes, I'd prefer to use a command like popup to open a new
>> window, perhaps something like:
>>
>> popup "+ term { class=gfxterm }"
>>
>> Then we can bind it to specific keys using onkey event:
>>
>> +onkey
>> {
>> key = "e"
>> command = "popup \"+ edit { class=edit_box text=\\\"$CURITEM\\\" }\""
>> }
>
> I thought that the editbox should be able to actually edit something
> but currently it is not so, it loads a list of commands from the item
> and either the list is executed (possibly after modifications) or it
> is thrown away so this would probably work.
>
> But it is still somewhat problematic because this does not tie the
> edit the the particular label which is going to be edited.
>
> If the label was special in some way (ie linux kernel versus other
> kernel) and it was somehow reflected in its properties (which is easy
> because linux kernels are done with 10_linux in grub.d while others
> are done elsewhere) or it was the single user variant this information
> is lost now. What I have in mind here is that people might want the
> edit dialog for a red menu item to have red border or something like
> that.
>
> This also makes password protection somewhat hard to hook in. If
> editing the item is password protected and this key is bound globally
> then this seems to bypass the password unless special measures are
> taken.
>
> Also there is not only "edit action" but also "execute action" key
> binding that applies to labels with an action. This should be also
> globally(?) customizable,but possibly password protected.
>
> It's not like the "onkey" handler cannot check the password protection
> properties but it's more natural (and probably easier to understand in
> the code) if this is handled in the component itself.
>
Hi,
Right, the previous example doesn't cover the data binding between
edit box and popup window, perhaps we can write something like this:
(text is the attribute name).
popup " + edit { src=text }"
We could have multiple edit box, for example, one to edit label,
another to edit content.
As for password protection, we could just use a attribute, for example:
+ onkey
{
key = "F1"
password = "true"
command = "..."
}
We could also put the password attribute in css. With this, we can
fine tune which command needs protection.
>>
>> + onkey
>> {
>> key = "c"
>> command = "popup \"+ term { class=term_box }\""
>> }
>
> This is fine, it opens a terminal which is just a new toplevel window.
> I would prefer the keyword was "show" instead of "popup" because it
> should hide the current window and show the one specified instead.
> Popup typically refers to a small additional window in windowing
> systems (and we don't really need a windowing system, only
> single-window system should be fine).
>
> The other thing with onkey is that if you want to make the key known
> you have to replicate the information somewhere in a label.
> It might be better to have an element that reacts to a hotkey and also
> displays it.
>
> ie
>
> + label {
> text = Help
> hotkey = F1,h
> action {
> show {
>
> <message box with text generated in grub.d scripts>
> }}}
>
> or if this is easier
>
> + hotkey {
> key = F1,h
> + label {
> text = Help
> ....
>
> # problematic keys
> key = space,comma
Each label can have associated hotkey, but onkey is different, it's
the event dispatcher, for example:
+ menu
{
+ onkey
{
key = "c"
password = "true"
command = ""
}
+ onkey
{
key = "e"
password = "true"
command = ""
}
+ label
{
text = "help"
hotkey = "F1"
}
+ label
{
text = "1. Boot Windows"
password = "true"
hotkey = "1"
}
}
Pressing F1 or 1 select the item, while pressing c or e laugh specific
command, regardless of which item is currently selected.
>
> I wonder if writing the whole element structure in the show command
> directly is the best approach. Perhaps the show commnad should only
> accept a class name and try to find a previously defined toplevel (not
> inside other element) panel with that class or perhaps there should be
> some other naming that would make it possible to define and recall
> windows.
Yep, both method works. In previous post, I've suggested adding dialog
tree, then we can use something like "show dialog_name". But being
able to embed the component in a string means we can construct it
dynamically, this could be useful when appending to the component tree
in sh/lua script.
--
Bean
gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
