Re: [GITGRUB] New menu interface (second draft)

[Bean]

On Thu, Sep 10, 2009 at 3:26 PM, Michal Suchanek <address@hidden> wrote:
> I don't know why you would move or resize a window. If there is only
> one window displayed it should get sized and placed reasonably from
> the start. Since grub has no threading you cannot have something like
> two applications running in parallel. At least we have nothing
> remotely similar to that now and I do not know about any plans for
> that either.

There could be more than one window, for example, we can have a menu
window and terminal window, user uses ctrl-tab to switch between them.
Only one of them receives input focus, so threading is not needed. And
it can also be used for small widgets like clock. Although some of
feature like the mouse support is not implemented yet, so windows is
not very useful at this point.

> There are two reasons to make this the basic label component:
>
>  - if you need just text the image is simply omitted at no cost to the user
>  - if you want an image and there is only a component that displays an
> image and text it should hint the user to also include a description
>  - adding icons to boot menu items is probably going to be the most
> common use of images so managing the compound in a single component
> should ease writing config files
>  - you can probably add the image later like
>
> + panel {
> class = main
>  + label {
>   class = grub_title
>   text = Grub $version
>  }
>  + panel {
>  class = boot_menu
>  + label {
>   class = linux
>   action {
>    linux /boot/vmlinuz...
>  ...
>
> style (class = linux) {
>  icon = Tux.png
>  icon-position = left
> }

I believe we have approached this in different direction. I'm more
inclined to create simple component first, then build complex ones
from it, while you like component that can handle many situation. The
end result would be the same, but I think my approach is more
extensible:

text - text only
image - image only
label - text plus image

For normal user, label would be enough, but if he wants to create
customized components in grub/lua script, it'd be useful to access
lower level components like text and image.

> I think that styling based on some user-defined selectors (shown as
> class in the mockups) gives pretty much all you can get this way
> without scripting new components in lua or something.
>
> Unfortunately the components written in C probably would not be very
> extensible. If I decided I am bored with rectangular panels and wanted
> a different shape it would be probably hard to write a new layout
> manager for panel in lua and add it to the existing panel.

The class method only works for one component, it won't work if it
involves more than one component. For example, we can define a confirm
dialog box with a panel, a label and the YES/NO button.

> I am using the current key bindings in gfxterm to make this clear.
> Obviously these can be changed but the default should mimic current
> gfxterm to ease transition from older grub.

Ok.

> We don't need a shell parser, it's in the shell already, and we cannot
> modify it, it's outside of grub.
>
> I do not get what you meant here.
>
> The shell is already used to execute /etc/grub.d/* and
> /usr/lib/grub/grub-mkconfig_lib and there are many utility functions
> in /usr/lib/grub/grub-mkconfig_lib for creating grub.cfg snippets.
>
> There is no need to make everything in grub if it's simple enough to
> be written in a shell function outside of grub.

Oh, I thought you mean the sh parser in grub.cfg, whose function is
quite limited.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/