On Sun, Sep 13, 2009 at 7:26 PM, Michal Suchanek <hramr...@centrum.cz> 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/
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
