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
Thanks
Michal
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
