Re: [PATCH] Refuse to install on XFS destroying its superblock
On Sun, Oct 18, 2009 at 06:30:11PM +0200, Vladimir 'phcoder' Serbinenko wrote: Robert Millan wrote: On Sat, Oct 17, 2009 at 02:09:31PM +0200, Vladimir 'phcoder' Serbinenko wrote: The danger is that fs_probe may reject filesystem as valid just because it's newer than expected. What do you mean with reject filesystem as valid? Sorry for being unclear. I just meant that if some XFS structures are updated then our xfs driver won't recognise it as xfs What do you mean with updated? You mean a new implementation of XFS? Or the same instance of XFS that has been modified after use? I mean next version on XFS Sorry, but what did you expect? You want to prevent PEBCAK using heuristic. There's no way we can tell if those 512 bytes are valuable data, only the user can. And even if you try to err on the safest side, there's no garantee that newer versions of XFS, or other filesystems that don't even exist yet will be detectable by us no matter what we do. Why don't we just take a backup like someone suggested a while ago? I think there was even a patch. This way if valuable data is lost, user can restore it (and while at it, learnt his lesson that filesystems and embedded code aren't really supposed to be mixed in the same place). -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
On Mon, Oct 19, 2009 at 05:02:13PM +0800, Bean wrote: Hi, Update: Now pxe fs exports PXE_MAC and PXE_IP on startup. Hi Bean, Are you going to provide a patch? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Refuse to install on XFS destroying its superblock
Robert Millan wrote: On Sun, Oct 18, 2009 at 06:30:11PM +0200, Vladimir 'phcoder' Serbinenko wrote: Robert Millan wrote: On Sat, Oct 17, 2009 at 02:09:31PM +0200, Vladimir 'phcoder' Serbinenko wrote: The danger is that fs_probe may reject filesystem as valid just because it's newer than expected. What do you mean with reject filesystem as valid? Sorry for being unclear. I just meant that if some XFS structures are updated then our xfs driver won't recognise it as xfs What do you mean with updated? You mean a new implementation of XFS? Or the same instance of XFS that has been modified after use? I mean next version on XFS Sorry, but what did you expect? You want to prevent PEBCAK using heuristic. There's no way we can tell if those 512 bytes are valuable data, only the user can. And even if you try to err on the safest side, there's no garantee that newer versions of XFS, or other filesystems that don't even exist yet will be detectable by us no matter what we do. I think best way is to have whitelist of OS which have first sector free and possible manual override like it was suggested. Why don't we just take a backup like someone suggested a while ago? I think there was even a patch. This way if valuable data is lost, user can restore it (and while at it, learnt his lesson that filesystems and embedded code aren't really supposed to be mixed in the same place). The backup is inevitably stored on the filesystem itself which becomes inaccessible once superblock is destroyed. -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] Support PXE option and new command pxecfg
On Tue, Oct 20, 2009 at 6:21 PM, Robert Millan r...@aybabtu.com wrote: On Mon, Oct 19, 2009 at 05:02:13PM +0800, Bean wrote: Hi, Update: Now pxe fs exports PXE_MAC and PXE_IP on startup. Hi Bean, Are you going to provide a patch? Hi, Here is it, the command pxecfg is skipped as it depends on my menu system. -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ pxe.diff Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
Hi,
Update:
Add dialog support, it allows you to write a template and call it with
different parameters, for example:
dialog_edit {
panel {
parameters = text=edit.text
class = frame
width = 80%
attach_hcenter = 0
attach_vcenter = 0
edit {
lines = 10
}
}
}
The parameters property control the mapping between parameter and
internal property name. To use it to edit current command:
menu_edit dialog_edit text=command
It also allows you to edit other properties, for example, the demo add
a hotkey t to edit the title:
t = menu_edit dialog_edit text=title\nmenu_refresh
The generated menu also uses templates, one for submenu, and one for menuitem:
menu_template {
panel {
class = frame
}
}
item_template {
panel {
parameters = class=image.class:title=text.text
class = select
image {}
text {}
}
}
The names of the template is passed to menu_create command:
menu_create menu_template item_template.
Smart popup window. The sub menu would pop to the direction with the
most space, which would make sure it won't be truncated by the border.
For example, if the parent menu is at the top of screen, sub menu pops
at the bottom, if it's at the bottom, sub menu pops at the top.
add command menu_next_node, menu_prev_node, menu_next_anchor and
menu_prev_anchor, you can assign these to other keys. The demo adds
the two terminal example. Inside terminal, direction key and TAB are
all used, so you need to assign another hotkey to switch between the
two window. The demo uses f6:
f6 = menu_next_anchor
Set maximum text mode in EFI.
--
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
Re: powerpc/sparc problems
Felix Zielcke wrote: Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke: And also anyone who has access to a powerpc machine (and experience)? Oh and I forgot to mention, that the powerpc version doestn't even build now with 1.97~beta4: _restgpr_31_x in boot is not defined Full build log is here: https://buildd.debian.org/fetch.cgi?pkg=grub2ver=1.97~beta4-1arch=powerpcstamp=1254771207file=log Hello Felix, I now reach to install grub for my debian unstable installation on my ibm p5 lpar (the unstable 1.97~beta3-1) but unfortunately failed to boot because failed to find a symbol (sorry I forget to take note of it). I so jump to svn (release 2641 and today 2642); no luck always this same error: _restgpr_31_x in boot is not defined I so re-try to build the deb pkg 1.97~beta3-1; too bad again this same error??? Could it be so a gcc issue (debian build of 1.97~beta3-1 was with gcc-4.4 4.4.1-3; here I rebuild with gcc-4.4 4.4.1-6 and even most recent 4.4.2-1?) I so try to come back to gcc 4.3 and this time it build fine (not yet tested if this one boot, sorry). Any idea? Tia, j. ps: I also tried to test bean123 git branch (grab this Oct 19) but this failed to build early to compile normal/main.c (gcc didn't find some references to some grub_... struct and fnct) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
Hello
2009/10/17 Bean bean12...@gmail.com:
Hi,
Update:
Add sub menu support, generate widgets dynamically using menu entries.
The example is very complex and I don't quite understand what is the
advantage of this baroque scheme over generating the menus in grub.d
in files like 00_header or 10_linux.
For example, each menuentry for loading a linux kernel is generated by
a function in 10_linux which in turn calls functions from
grub-mkconfig_lib. Thus it is possible to create arbitrarily complex
menu entries without additional C code in grub or user-edited
configuration. I don't see why these shell scripts cannot include all
the panels and stuff needed for the new menu and have to be generated
by C code in grub.
Now grub.cfg should look like this:
menuentry AAA {
set root=(hd0,1)
chainloader +1
}
menuentry BBB --class ubuntu {
true
}
. /menu/menu.cfg
The menu have three items, AAA, BBB and Tools, which is a menu
appended in menu.cfg.
Tools are a submenu, its content is defined using menu section:
menu {
Tools {
Toggle Mode {
command = menu_toggle_mode
}
Terminal {
command = menu_popup term_window
}
Change Theme {
Default {
command=load_config /menu/blue.txt\nmenu_refresh
}
Green {
command=load_config /menu/green.txt\nmenu_refresh
}
White {
command=load_config /menu/white.txt\nmenu_refresh
}
}
Layout Demo {
command = menu_popup layout_test
}
Halt {
command = halt
}
Reboot {
command = reboot
}
}
}
merge_config command would append this with user defined menu items.
The screen section is very simple now:
screen {
panel {
extend = 1
valign = center
halign = center
panel {
class = frame
id = __menu__
}
}
}
So you invent a new property here just to bind the menu to a panel. If
you insist then screen should be a panel { id = __screen__ }.
command menu_create would scan screen for id __menu__, and add widgets
according to the menu content. The generated widget entry looks like
this:
panel
{
class = select
command = COMMAND
image { class = CLASS }
text { text = TITLE }
}
And if I want a slightly different structure I have to patch and
recompile grub. I also wonder how do you specify the image bitmap here
because it's the sole content of the image so it should not be
specified by style.
The submenu is this:
panel
{
class = frame
command = menu_popup -r menu_tree N
}
I have no idea what the above is supposed to mean. Care to explain?
Thanks
Michal
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
2009/10/18 Bean bean12...@gmail.com:
Hi,
Update:
Add mapkey section. For example:
mapkey {
f5 = ctrl-x
}
Does this also generate a mapkey text which you can dump into a text
box so that people know what is mapped to what (and the same for the
default bindings and grub version/last git commit)?
Wouldn't it be more practical and transparent to just make the
mappings configurable?
That is write the current mappings as key-function assignments and
then allow change mappings / add new mappings.
maps f5 key to ctrl-x, this is important for platforms like EFI as
ctrl-x can't be input.
key name should be lowercase, it can be single character, f1 to f10,
ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
page_down, esc, tab, backspace and space.
Add onkey section, which allow you to assign a function when a key is
pressed. For example ,this is the onkey section for the demo:
onkey {
c = menu_popup term_window
e = menu_popup edit_window edit.text=command
f7 = menu_popup layout_test
f8 = menu_toggle_mode
f9 = halt
f10 = reboot
}
This should be merged with the mapkey into a single key mapping function.
c open a terminal window, e open a edit box to edit the current
command, use ctrl-x to save it. f7 runs the layout demo test, f8
toggle between text and graphic mode, f9 shutdown, f10 reboot.
Data binding for popup windows, for example, in the above example,
menu_popup edit_window edit.text=command
property text in the edit widget in the popup dialog binds to the
command property of current node, this is used to implement the edit
function.
Add two property attach_hcenter and attach_vcenter for layout manager.
What is the actual use case for windows which are not managed in the
layout and thus potentially overlap other windows in a system where
window overlapping is not handled?
The top widget of popup window must use absolute position, as widget
are already placed in screen and can't be moved without refresh. But
it's not easy to put the widget in the middle of screen using
attach_left/right/top/bottom, the new property attach_hcenter and
attach_vcenter defines the offset from the center of screen.
Can't you just make the popup fullscreen?
IMHO it rids us of quite a few things that allow people to shoot
themselves in the foot and require documentation and maintenance while
not removing anything particularly useful.
Support TAB completion for term widget.
That's very nice.
Thanks
Michal
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
rubisher wrote: Felix Zielcke wrote: Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke: And also anyone who has access to a powerpc machine (and experience)? Oh and I forgot to mention, that the powerpc version doestn't even build now with 1.97~beta4: _restgpr_31_x in boot is not defined Full build log is here: https://buildd.debian.org/fetch.cgi?pkg=grub2ver=1.97~beta4-1arch=powerpcstamp=1254771207file=log Hello Felix, I now reach to install grub for my debian unstable installation on my ibm p5 lpar (the unstable 1.97~beta3-1) but unfortunately failed to boot because failed to find a symbol (sorry I forget to take note of it). I so jump to svn (release 2641 and today 2642); no luck always this same error: _restgpr_31_x in boot is not defined From the name and what we discussed with Felix on IRC I guess this symbol is a counterpart of MIPS' __gnu_local_gp which is used in handling GOT relocations which allow usage of a single instruction to load 32-bit address instead of usual 2 but require linker to generate additional table. You can look into kern/mips/dl.c of my mips branch for details. Similar approach can be used for powerpc. I suppose it would be a good idea to put this code to kern/got.c instead of kern/arch. But such a change just before release is too big. Since it correspond to a recent change in gcc behaviour perhaps an old behaviour can be restored with an option. I so re-try to build the deb pkg 1.97~beta3-1; too bad again this same error??? Could it be so a gcc issue (debian build of 1.97~beta3-1 was with gcc-4.4 4.4.1-3; here I rebuild with gcc-4.4 4.4.1-6 and even most recent 4.4.2-1?) I so try to come back to gcc 4.3 and this time it build fine (not yet tested if this one boot, sorry). Any idea? Tia, j. ps: I also tried to test bean123 git branch (grab this Oct 19) but this failed to build early to compile normal/main.c (gcc didn't find some references to some grub_... struct and fnct) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] auto-generate libgcc.h
This should be a much cleaner option than maintaining libgcc.h by hand. Only tested on sparc, but it should also cast out the build problems on powerpc. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. 2009-10-20 Robert Millan rmh.g...@aybabtu.com * genlibgcc_h.sh.in: New file. * conf/powerpc-ieee1275.rmk (MOSTLYCLEANFILES): Add `libgcc.h'. (libgcc.h): New rule. (kernel_syms.lst): Add `libgcc.h' to header list. * conf/sparc64-ieee1275.rmk: Likewise. * include/grub/sparc64/libgcc.h: Remove. Update all users. * include/grub/powerpc/libgcc.h: Likewise. * configure.ac: Stop checking for libgcc symbols. * include/grub/misc.h [!GRUB_UTIL] (memset, memcmp): New prototypes (provided by libc.so or kernel.img, NOT libgcc). Index: conf/powerpc-ieee1275.rmk === --- conf/powerpc-ieee1275.rmk (revision 2641) +++ conf/powerpc-ieee1275.rmk (working copy) @@ -10,19 +10,22 @@ script/sh/lexer.c_DEPENDENCIES = grub_script.tab.h # Images. -MOSTLYCLEANFILES += symlist.c kernel_syms.lst +MOSTLYCLEANFILES += symlist.c kernel_syms.lst libgcc.h DEFSYMFILES += kernel_syms.lst kernel_img_HEADERS = boot.h cache.h device.h disk.h dl.h elf.h elfload.h \ env.h err.h file.h fs.h kernel.h misc.h mm.h net.h parser.h reader.h \ - symbol.h term.h time.h types.h powerpc/libgcc.h loader.h partition.h \ + symbol.h term.h time.h types.h loader.h partition.h \ msdos_partition.h ieee1275/ieee1275.h machine/kernel.h handler.h list.h \ command.h +libgcc.h: genlibgcc_h.sh + /bin/sh $ $@ || (rm -f $@; exit 1) + symlist.c: $(addprefix include/grub/,$(kernel_img_HEADERS)) config.h gensymlist.sh /bin/sh gensymlist.sh $(filter %.h,$^) $@ || (rm -f $@; exit 1) -kernel_syms.lst: $(addprefix include/grub/,$(kernel_img_HEADERS)) config.h genkernsyms.sh +kernel_syms.lst: $(addprefix include/grub/,$(kernel_img_HEADERS)) libgcc.h config.h genkernsyms.sh /bin/sh genkernsyms.sh $(filter %.h,$^) $@ || (rm -f $@; exit 1) # Programs Index: conf/sparc64-ieee1275.rmk === --- conf/sparc64-ieee1275.rmk (revision 2641) +++ conf/sparc64-ieee1275.rmk (working copy) @@ -23,14 +23,14 @@ diskboot_img_ASFLAGS = $(COMMON_ASFLAGS) diskboot_img_LDFLAGS = $(COMMON_LDFLAGS) -Wl,-N,-Ttext,0x4200 diskboot_img_FORMAT = binary -MOSTLYCLEANFILES += symlist.c kernel_syms.lst +MOSTLYCLEANFILES += symlist.c kernel_syms.lst libgcc.h DEFSYMFILES += kernel_syms.lst kernel_img_HEADERS = boot.h cache.h device.h disk.h dl.h elf.h elfload.h \ env.h err.h file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h \ partition.h msdos_partition.h reader.h symbol.h term.h time.h types.h \ list.h handler.h command.h \ - sparc64/libgcc.h ieee1275/ieee1275.h machine/kernel.h \ + ieee1275/ieee1275.h machine/kernel.h \ sparc64/ieee1275/ieee1275.h kernel_img_SOURCES = kern/sparc64/ieee1275/crt0.S kern/ieee1275/cmain.c \ kern/ieee1275/ieee1275.c kern/main.c kern/device.c \ @@ -54,7 +54,10 @@ kernel_img_FORMAT = binary symlist.c: $(addprefix include/grub/,$(kernel_img_HEADERS)) config.h gensymlist.sh /bin/sh gensymlist.sh $(filter %.h,$^) $@ || (rm -f $@; exit 1) -kernel_syms.lst: $(addprefix include/grub/,$(kernel_img_HEADERS)) config.h genkernsyms.sh +libgcc.h: genlibgcc_h.sh + /bin/sh $ $@ || (rm -f $@; exit 1) + +kernel_syms.lst: $(addprefix include/grub/,$(kernel_img_HEADERS)) libgcc.h config.h genkernsyms.sh /bin/sh genkernsyms.sh $(filter %.h,$^) $@ || (rm -f $@; exit 1) # Utilities. Index: configure.ac === --- configure.ac (revision 2642) +++ configure.ac (working copy) @@ -411,9 +411,6 @@ AC_SUBST(TARGET_ASFLAGS) AC_SUBST(TARGET_CPPFLAGS) AC_SUBST(TARGET_LDFLAGS) -# Check for libgcc symbols (must be performed before we add -nostdlib to LDFLAGS) -AC_CHECK_FUNCS(__bswapsi2 __bswapdi2) - # Set them to their new values for the tests below. CC=$TARGET_CC if test x$TARGET_APPLE_CC = x1 ; then @@ -615,7 +612,7 @@ else rm -rf include/grub/machine cp -rp $srcdir/include/grub/$target_cpu/$platform include/grub/machine 2/dev/null fi -AC_CONFIG_FILES([Makefile gensymlist.sh genkernsyms.sh]) +AC_CONFIG_FILES([Makefile gensymlist.sh genkernsyms.sh genlibgcc_h.sh]) AC_CONFIG_FILES([stamp-h], [echo timestamp stamp-h]) AC_OUTPUT [ Index: include/grub/misc.h === --- include/grub/misc.h (revision 2641) +++ include/grub/misc.h (working copy) @@ -78,6 +78,8 @@ grub_strncat (char *dest, const char *src, int c) #if !defined (GRUB_UTIL) || !defined (APPLE_CC) void *EXPORT_FUNC(memmove) (void *dest, const void *src, grub_size_t n); void *EXPORT_FUNC(memcpy) (void *dest, const void *src,
Re: [GITGRUB] New menu interface (implementation)
I find that the 2 terminal configuration with hotkey switch can be very useful alternative in some situations (debugging ...) , particularly on 1920x1200 screen. Single screen popup can be default for normal use. On Wed, Oct 21, 2009 at 6:31 AM, Michal Suchanek hramr...@centrum.czwrote: 2009/10/20 Bean bean12...@gmail.com: menu_prev_anchor, you can assign these to other keys. The demo adds the two terminal example. Inside terminal, direction key and TAB are all used, so you need to assign another hotkey to switch between the two window. The demo uses f6: f6 = menu_next_anchor This is an interesting addition but I'm not sure where this would be used. Normally one terminal is enough so you can just open it fullscreen and close it when you want to do something else. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Wed, Oct 21, 2009 at 3:06 AM, Michal Suchanek hramr...@centrum.cz wrote:
Hello
2009/10/17 Bean bean12...@gmail.com:
Hi,
Update:
Add sub menu support, generate widgets dynamically using menu entries.
The example is very complex and I don't quite understand what is the
advantage of this baroque scheme over generating the menus in grub.d
in files like 00_header or 10_linux.
For example, each menuentry for loading a linux kernel is generated by
a function in 10_linux which in turn calls functions from
grub-mkconfig_lib. Thus it is possible to create arbitrarily complex
menu entries without additional C code in grub or user-edited
configuration. I don't see why these shell scripts cannot include all
the panels and stuff needed for the new menu and have to be generated
by C code in grub.
Hi,
Don't forget that menu items can be generated at runtime. For example,
with my osdetect,lua script, it's possible to scan the disk for
existing OS and add them to the menu automatically, so a generic
config file can be used. This is quite useful in removable boot media
like usb and cdrom, as you can't predict in advanced what OS would be
present when the media boots. In this case, the menu have to be
generated dynamically as well.
Now grub.cfg should look like this:
menuentry AAA {
set root=(hd0,1)
chainloader +1
}
menuentry BBB --class ubuntu {
true
}
. /menu/menu.cfg
The menu have three items, AAA, BBB and Tools, which is a menu
appended in menu.cfg.
Tools are a submenu, its content is defined using menu section:
menu {
Tools {
Toggle Mode {
command = menu_toggle_mode
}
Terminal {
command = menu_popup term_window
}
Change Theme {
Default {
command=load_config /menu/blue.txt\nmenu_refresh
}
Green {
command=load_config /menu/green.txt\nmenu_refresh
}
White {
command=load_config /menu/white.txt\nmenu_refresh
}
}
Layout Demo {
command = menu_popup layout_test
}
Halt {
command = halt
}
Reboot {
command = reboot
}
}
}
merge_config command would append this with user defined menu items.
The screen section is very simple now:
screen {
panel {
extend = 1
valign = center
halign = center
panel {
class = frame
id = __menu__
}
}
}
So you invent a new property here just to bind the menu to a panel. If
you insist then screen should be a panel { id = __screen__ }.
id can be useful in templates to name children widgets having the same name.
command menu_create would scan screen for id __menu__, and add widgets
according to the menu content. The generated widget entry looks like
this:
panel
{
class = select
command = COMMAND
image { class = CLASS }
text { text = TITLE }
}
And if I want a slightly different structure I have to patch and
recompile grub. I also wonder how do you specify the image bitmap here
because it's the sole content of the image so it should not be
specified by style.
See my latest patch, this have already been replaced by templates. You
specify the template names in menu_create command:
menu_create menu_template item_template
item_template {
panel {
parameters = class=image.class:title=text.text
class = select
direction = left_to_right
image {}
text { valign = center }
}
}
In the template, parameters property sets the mapping between external
parameter name and internal properties. for example, this example
shows class is mapped to class property of image widget, and title is
mapped to text property of text widget.
The submenu is this:
panel
{
class = frame
command = menu_popup -r menu_tree N
}
I have no idea what the above is supposed to mean. Care to explain?
menu_popup create a popup window using template, menu_tree is an
section auto generated by menu_create, N is the index of children
widget. BTW, the syntax has changed in the latest patch to:
menu_popup -ri N menu_tree
The index is moved as option, as we can append assignment after the name.
--
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
Re: [GITGRUB] New menu interface (implementation)
On Wed, Oct 21, 2009 at 3:20 AM, Michal Suchanek hramr...@centrum.cz wrote:
2009/10/18 Bean bean12...@gmail.com:
Hi,
Update:
Add mapkey section. For example:
mapkey {
f5 = ctrl-x
}
Does this also generate a mapkey text which you can dump into a text
box so that people know what is mapped to what (and the same for the
default bindings and grub version/last git commit)?
Wouldn't it be more practical and transparent to just make the
mappings configurable?
That is write the current mappings as key-function assignments and
then allow change mappings / add new mappings.
maps f5 key to ctrl-x, this is important for platforms like EFI as
ctrl-x can't be input.
key name should be lowercase, it can be single character, f1 to f10,
ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
page_down, esc, tab, backspace and space.
Add onkey section, which allow you to assign a function when a key is
pressed. For example ,this is the onkey section for the demo:
onkey {
c = menu_popup term_window
e = menu_popup edit_window edit.text=command
f7 = menu_popup layout_test
f8 = menu_toggle_mode
f9 = halt
f10 = reboot
}
This should be merged with the mapkey into a single key mapping function.
Hi,
The difference of mapkey and onkey is when they're executed. The order
is as follows:
mapkey
onkey function of current widget
key binding in onkey section
For example in the edit widget, you use ctrl-x to finish current edit.
But in EFI, you can't input ctrl-x. The way to solve this is to map
another key as ctrl-x, which use mapkey function. Adding function in
onkey doesn't help, as by the time it reaches there, the edit widget
has finish handling.
Also, if the key is used by widget, the binding in onkey doesn't help.
This is actually a good thing, for example, we can add hotkey c to
open a terminal window. This has effect on main menu, but we certainly
don't want it when inside term already. But if we do need to change a
key used by widget, we can map it in mapkey section.
c open a terminal window, e open a edit box to edit the current
command, use ctrl-x to save it. f7 runs the layout demo test, f8
toggle between text and graphic mode, f9 shutdown, f10 reboot.
Data binding for popup windows, for example, in the above example,
menu_popup edit_window edit.text=command
property text in the edit widget in the popup dialog binds to the
command property of current node, this is used to implement the edit
function.
Add two property attach_hcenter and attach_vcenter for layout manager.
What is the actual use case for windows which are not managed in the
layout and thus potentially overlap other windows in a system where
window overlapping is not handled?
Popup window. For example, the e hotkey popup a edit box to edit
current command. The top window of popup is placed in screen directly
and not controlled by layout manger.
The top widget of popup window must use absolute position, as widget
are already placed in screen and can't be moved without refresh. But
it's not easy to put the widget in the middle of screen using
attach_left/right/top/bottom, the new property attach_hcenter and
attach_vcenter defines the offset from the center of screen.
Can't you just make the popup fullscreen?
IMHO it rids us of quite a few things that allow people to shoot
themselves in the foot and require documentation and maintenance while
not removing anything particularly useful.
You can configure the sub menu to pop up full screen. But I like it
alongside the parent menu. IMO, this is the most common way to display
a submenu.
--
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
Re: [GITGRUB] New menu interface (implementation)
On Wed, Oct 21, 2009 at 3:31 AM, Michal Suchanek hramr...@centrum.cz wrote:
2009/10/20 Bean bean12...@gmail.com:
Hi,
Update:
Add dialog support, it allows you to write a template and call it with
different parameters, for example:
dialog_edit {
panel {
parameters = text=edit.text
class = frame
width = 80%
attach_hcenter = 0
attach_vcenter = 0
edit {
lines = 10
}
}
}
I can see this used for the edit boxen and text mesasge dialogs which
would be quite similar.
Also the templating seems quite flexible and versatile.
However, can't this be done with a shell function?
Both the grub.d scripts and grub.cfg can define a function with a few
parameters to achieve pretty much the same results.
IIRC one of the sample menu.cfg files defined functions as part of
grub configuration so we do not need another facility for this.
Hi,
IMO it's more easy to write widget this way, you can still pack it in
shell script as menu_popup support string argument:
menu_popup -s panel { width=100% height=100% }
This is fine for short code, but as the widget become more complex,
it's quite difficult to use this notion, especially when you add
command property which requires quotes. There seems to be some issue
with embedded quote handling.
The parameters property control the mapping between parameter and
internal property name. To use it to edit current command:
menu_edit dialog_edit text=command
It also allows you to edit other properties, for example, the demo add
a hotkey t to edit the title:
t = menu_edit dialog_edit text=title\nmenu_refresh
The generated menu also uses templates, one for submenu, and one for
menuitem:
menu_template {
panel {
class = frame
}
}
item_template {
panel {
parameters = class=image.class:title=text.text
class = select
image {}
text {}
}
}
The names of the template is passed to menu_create command:
menu_create menu_template item_template.
Smart popup window. The sub menu would pop to the direction with the
most space, which would make sure it won't be truncated by the border.
It won't. You cannot know how much space the most space is.
First I calculate the central point of current node, if it's in the
top-left quadrant, I pop up sub menu at its bottom-right corner, etc.
The handling is quite simple and it should avoid popping up sub menu
off screen.
--
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
