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

[Michal Suchanek]

2009/9/10 Bean <address@hidden>:
> 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.

Why do you need two windows for that?

You can put a terminal and a menu into a single window. That's
actually what most terminal emulators do.

I don't think grub should start doing window management. It does not
share the screen with anything else, packing multiple elements loosely
so that they can be moved only wastes screen space and window
management adds complexity with no benefit.

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

Yes, primitive drawing functions should be available in lua for
creating custom components. But that would not be a text component but
functions to draw text, images, etc.

Perhaps it would be a good idea to implement a sample component in lua
to find out what parts of the C components can be reused and should be
exported.

Creating components in advance only to be used as part of lua
scripting may be a case of premature optimization. At this point it is
not obvious if such components are helpful and what components would
be needed.

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

It must work.

For a dialog like

+ panel {
  class = mydialog
  + label {
   class = text
    text = some message
  }
  + panel {
   class = buttonbar
   + label {
    class = button,yes
    text = YES
    action {
    ...
    }
    + label {
     class = button,no
     text = NO
     action {
     ...
     }
   }
 }
}

CSS selector allow something like

.mydialog panel .button

to select a button inside a panel inside a mydialog element.

Similarly X resources allow syntax like

*mydialog*button

to select any buttons in mydialog.

Without a mechanism like this any styling would be hardly possible at all.

Also if the dialog is not a fixed element but rather a compound that
is written into the grub.cfg by update-grub every subelement can be
styled separately with the most flexibility.

Compound components cause great troubles when they are presented as
one opaque element because changing all aspect of such complex element
requires huge number of properties (see the problem with the Mozilla
file upload form element - edit box + button)

Thanks

Michal