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

[Bean]

On Sun, Sep 13, 2009 at 7:26 PM, Michal Suchanek <address@hidden> wrote:
> Hello
>
> I hope this long discussion has not put you off.
>
> I personally would probably go with leaving gfxterm in place until a
> better menu is really needed but having a nice customizable menu is
> nice and will surely attract more potential grub users.
>
> I want the new menu system to be as simple and extensible as possible
> for several reasons.
>
> First people would probably want to write themes for the menu to
> change its look in new and unexpected ways. It has been the case with
> both grub legacy and syslinux and hopefully by creatind a menu system
> flexible enough we could prevent a grub2-with-fancy-graphics fork.
>
> Second if we introduce some features and menu system components now it
> will be hard to remove them later so I want to have as few components
> as necessary initially and only add new ones if/when there are useful
> features not covered by the initial components.
>
> Lastly I will be likely also dealing with the new menu when it gets
> into mainline grub so I would like it to be somewhat reasonable.
>
> The problem I see now is that some selector for styling need to be designed.
>
> This should help both people styling the menu and creating distinct
> components from the basic ones in the standard menu.
>
> The two systems that I know that have some decent selectors are
>
>  - X resources
>
>  This system has the deficiency that AFAIK each object can have at
> most one class. Properties themselves are nodes in the class tree.
> Parts if the path in the tree can be omitted.
>  Given something like XTerm.vt100.foreground  properties that apply
> include this full path, XTerm..foreground (name of one component
> omitted) ..foreground (names of two components omitted), *foreground
> (applies to any foreground), XTerm*foreground (would also apply to,
> say XTerm.foreground)
>
>  - CSS selectors
>
>  These selectors can select by component type, component class, other
> attributes, states (like hover, focused, etc), etc.
>  Another interesting thing that you can do is styling :first-child.
>  However, this is very limited in utility without generalizing to
> arbitrary n-th child element and possibly odd/even/modN elements.
>  The limitation of these selector is that you can only omit part of
> path from the start
>  .XTerm .vt100 { foreground = <something> } would refer to that
> particular property as could probably something like
>  .v100 {}
>  window vt100 {}
>  I am not sure something like
>  .XTerm * {}
>  would be valid in CSS
>
> I would think that an option that combines the best of both is
> something like X resource selectors with qualifiers that select class
> or type or specify nth element.
>
> For example
>
> + panel {
>  class = main_menu
>  + label {
>   class = main,title # multiple classes
>   text = GRUB $version
>  }
>  + panel {
>   class = boot_menu,menu
>   + label {
>   ....
>  }
> }
>
> style main_menu*boot_menu.~label {
>  text-align: left;
>  icon-position: left;
>  background-color: blue;
>  color: yellow;
> }
>
> style main_menu*boot_menu.~label:focused {
>  background-color: yellow;
>  color: blue;
> }
>
> # style the default item differently given default is the number of
> the default item
> style main_menu*boot_menu.~label[default] {
>  color: red;
> }
>
> you could probably use
>
> style main_menu*boot_menu. {
> style main_menu*boot_menu.:focused {
> style main_menu*boot_menu.[default] {
>
> but not having any element specification at the end of the selector
> would make it hard to read.
>
> This should allow styling all element reasonably.
>
> The remaining question is how the styles should be resolved in case
> multiple selectors would apply to single element.
>
> One simple way is to just process everything in order - that is set
> the property at the time the element definition or style definitin is
> read from the file.
>
> This has the disadvantage that elements singled out earlier would be
> overwritten by a later blanket style covering everything. The
> advantage is that completely restyling some aspect of the menu is easy
> - you specify a single style that resets all colours and build your
> colouring on top of that.
> In CSS this is somewhat problematic. The styles with more specific
> selectors override styles with less specific selectors - overriding
> earlier specific styles requires the !mportant keyword and there are
> only two levels, overriding !important is not possible without
> duplicating all declarations of the previous styles.
>
> It seems that this is not a problem in X properties, though. This is
> probably because unlike HTML+CSS X resources tend to have very few
> generic defaults + some very application specific definitions that do
> not apply elsewhere so people restyling their desktop only need to set
> the properties they would need anyway if they started from scratch.
>
> Given that in Grub we would probably want some initial style it is
> probably better choice to override earlier styles with later styles
> regardless of specificity. This would probably require walking the
> component tree and (re-) set all components when styles are changed
> but would not require storing styles separately outside of component
> properties.
>
> The most specific style approach probably works better with a separate
> style store where each component looks for its style when it redraws
> and finds the style with most specific selector for each property
> (which can then be cached in its property values until styles change
> for the next time).
>
> Another somewhat peculiar issue are the elements that are not part of
> user layout. These would be:
>
> enter password box (the thing you would get by trying to run
> password-protected action)
> edit action box (the thing you get currently in boot menu by pressing e)
> edit environment value box (would be useful to set a specific
> environment variable without having to start console)
>
> These would be toplelevel (fullscreen windows) created by a grub
> command, not defined in the configuration file.
> Perhaps their class property could be copied from the label that
> executed them so that they can be styled specifically.
>
> ie
>
> + label {
>  text = Change graphics mode
>  class = set_gfxmode
>  action {
>  edit-env gfxmode
>  terminal_output gfxterm
>  }
> }
>
> would create an "edit environment variable" toplevel with class set_gfxmode

Hi,

Thanks a lot for your advice, most of them looks good, although some
details may need adjustment.

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\\\" }\""
}

+ onkey
{
  key = "c"
  command = "popup \"+ term { class=term_box }\""
}

-- 
Bean

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