Re: menu loop (patch)

Re: menu loop (patch)

[chaac]

"Yoshinori K. Okuji" [okuji@enbug.org] kirjoitti: 
> On Saturday 19 July 2008 21:58:09 Robert Millan wrote:
> > On Sat, Jul 19, 2008 at 10:34:46AM -0700, Colin D Bennett wrote:
> > > [...]  We could support a setting such as "set menuwrap=1" which
> > > would enable this feature for users who care about it.
> >
> > Isn't this a bit overkill?  The time spent adding this config option vastly
> > exceeds any time that could be saved by having or not having menu wrap.
> >
> > > Actually my graphical menu currently *does* wrap around, I guess it
> > > seemed logical to me at the time I wrote the code!  8-)  As you can
> > > tell, I am not firmly set on either wrapping or not wrapping.
> >
> > Same here..  my concern with taking arbitrary decisions is, when someone
> > comes later and asks to have it reverted, do we accept the request, and
> > otherwise what rationale do we give her? :-)
> 
> Personally, I prefer no wrapping, because it is easier for me to use only 
> Up/Down arrow keys, yet locate entries easily. Since I am lazy, I don't want 
> to look for Home or End (some keyboards really suck for them!), so when I 
> just want to jump to somewhere near to the end, I only keep pushing Down, and 
> wait for the cursor to stop. And, this is consistent with Dired mode in 
> Emacs, Directory Listing in VIM, and, of course, with GRUB Legacy.

Hi All,

I also like no wrapping mode. But lets assume we have nice graphical menu with "cylinder" of menu entries that roll when you press key up/down. In here it would be really convenient to have wraparound eg. user cant event think any other way here. But this is something I would put into theme configuration file.

Theme could be also loadable for text menu that describes colours and such. We could default to non-wrapping as that has been our way for long time. If user wants to override this in theme then they are free to do so.

In every case I would prefer that home and end keys would go to always to start and to end of the list. Page up/down would rely a bit for wrapping setting so they can clamp to list edges if needed.

Thanks,
Vesa Jääskeläinen

Re: menu loop (patch)

[Carles Pina i Estany]

Hi,

On Jul/20/2008, chaac@nic.fi wrote:

> In every case I would prefer that home and end keys would go to always
> to start and to end of the list. Page up/down would rely a bit for
> wrapping setting so they can clamp to list edges if needed.

home-end keys (without wrapping) are handled in a patch that I sent
yesterday in this thread (20 Jul 2008 00:12:43 +0200). I think that
Home-End keys are fine and I hope that everybody agrees :-)

I will also play with PgUp and PgDown soon or later :-)

-- 
Carles Pina i Estany		GPG id: 0x8CBDAE64
	http://pinux.info	Manresa - Barcelona

Re: menu loop (patch)

[Robert Millan]

On Sun, Jul 20, 2008 at 09:21:47AM +0300, chaac@nic.fi wrote:
> 
> I also like no wrapping mode. But lets assume we have nice graphical menu 
> with "cylinder" of menu entries that roll when you press key up/down.

Oh my god.  Tell me you're not planning to implement OpenGL in GRUB! ;-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: menu loop (patch)

[Vesa Jääskeläinen]

Robert Millan wrote:
> On Sun, Jul 20, 2008 at 09:21:47AM +0300, chaac@nic.fi wrote:
>> I also like no wrapping mode. But lets assume we have nice graphical menu 
>> with "cylinder" of menu entries that roll when you press key up/down.
> 
> Oh my god.  Tell me you're not planning to implement OpenGL in GRUB! ;-)

Well... OpenGL ES could be cool :)... but no... Cylinder effect with 
texts always facing to user is really easy to simulate to have 3D look.

menu loop (patch)

[Carles Pina i Estany]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]


Hello,

I'm a Grub user (thanks for your nice work!) and I always wanted to have
a menu that "loops". Like, if you press down and you are in the last
option it goes to the first one, and if you press up but you are int he
first option goes to the last.

Attached comes a patch against revision 1718.

Of course, feel free to comment anything about it. I'm open to change,
fix, etc.

I also don't know if this functionality is not in Grub because you
thought that was better to not have this functionality. 

I've copied/change a few lines (after the patch, lines 425-428 are the
same than lines 347-350). I don't think that it's needed to refactor but
if you think so I can do it.

Thank you,

-- 
Carles Pina i Estany		GPG id: 0x8CBDAE64
	http://pinux.info	Manresa - Barcelona

[-- Attachment #2: menu_loop.patch --]
[-- Type: text/x-diff, Size: 835 bytes --]

Index: normal/menu.c
===================================================================
--- normal/menu.c	(revision 1717)
+++ normal/menu.c	(working copy)
@@ -420,6 +420,17 @@
 		  first--;
 		  print_entries (menu, first, offset);
 		}
+	      else if (first==0) 
+	        {
+		  // Highlight the last entry
+		  offset = menu->size - 1;
+		  if (offset > GRUB_TERM_NUM_ENTRIES - 1)
+		     {
+			first = offset - (GRUB_TERM_NUM_ENTRIES - 1);
+			offset = GRUB_TERM_NUM_ENTRIES - 1;
+		     }
+		  print_entries (menu, first, offset);
+		}
 	      break;
 	      
 	    case 14:
@@ -440,6 +451,13 @@
 		      print_entries (menu, first, offset);
 		    }
 		}
+	      else
+	        {
+			// Highlight the first entry
+			first=0;
+			offset=0;
+			print_entries (menu, first, offset);
+		}
 	      break;
 	      
 	    case '\n':

Re: menu loop (patch)

[Robert Millan]

On Thu, Jul 17, 2008 at 11:22:27PM +0200, Carles Pina i Estany wrote:
> 
> Hello,

Carles!  Que n'és de petit el món ;-)

> I'm a Grub user (thanks for your nice work!) and I always wanted to have
> a menu that "loops". Like, if you press down and you are in the last
> option it goes to the first one, and if you press up but you are int he
> first option goes to the last.
> 
> Attached comes a patch against revision 1718.
> 
> Of course, feel free to comment anything about it. I'm open to change,
> fix, etc.
> 
> I also don't know if this functionality is not in Grub because you
> thought that was better to not have this functionality. 
> 
> I've copied/change a few lines (after the patch, lines 425-428 are the
> same than lines 347-350). I don't think that it's needed to refactor but
> if you think so I can do it.

I'm not sure if this is intentional.  Size is not important in this part of
the code, but in other UI menus (e.g. Iceweasel or GNOME) I notice this is
not done.  It could also be a nuissance for users who want to go rapidly to
the top or bottom (sure, they can use PgUp/PgDn, but then aren't we making
the behaviour of those keys inconsistent with arrows?).

Also, if you (or anyone) can point to a "usability best practices" reference
saying this has been carefuly analized and one of the options was found to be
better, I think this would help us make a decision.

What does everyone else think?

Colin, does this affect your graphical menu work in some way?  I suppose the
same situation applies the same way to the upcoming new menu.  Or perhaps
this can be made more flexible and be toggled by some CSS magic?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: menu loop (patch)

[Carles Pina i Estany]

Hello,

On Jul/19/2008, Robert Millan wrote:
> On Thu, Jul 17, 2008 at 11:22:27PM +0200, Carles Pina i Estany wrote:
> > 
> > Hello,
> 
> Carles!  Que n'és de petit el món ;-)

exacte! :-)

> > I'm a Grub user (thanks for your nice work!) and I always wanted to have
> > a menu that "loops". Like, if you press down and you are in the last
> > option it goes to the first one, and if you press up but you are int he
> > first option goes to the last.
> > 
> > Attached comes a patch against revision 1718.
> > 
> > Of course, feel free to comment anything about it. I'm open to change,
> > fix, etc.
> > 
> > I also don't know if this functionality is not in Grub because you
> > thought that was better to not have this functionality. 
> > 
> > I've copied/change a few lines (after the patch, lines 425-428 are the
> > same than lines 347-350). I don't think that it's needed to refactor but
> > if you think so I can do it.
> 
> I'm not sure if this is intentional.  Size is not important in this
> part of the code, but in other UI menus (e.g. Iceweasel or GNOME) I

fast check in KDE: it's looping

Also, Iceweasel menus are looping here (maybe because it's executed
in KDE and there is some GTK Widget with a different behaviour? I have
no idea)

> notice this is not done.  It could also be a nuissance for users who
> want to go rapidly to the top or bottom (sure, they can use PgUp/PgDn,
> but then aren't we making the behaviour of those keys inconsistent
> with arrows?).

I would be glad to add some functionality for PgUp/PgDown and also for
Home/End keys (I would do it today evening or tomorrow and send the
patch).

> Also, if you (or anyone) can point to a "usability best practices"
> reference saying this has been carefuly analized and one of the
> options was found to be better, I think this would help us make a
> decision.

I will also check tonight.

My patch is based on two things:
-what I was expecting as user (I always tried KeyUp to go to the end in
Grub -but not Home/End/PgUp/PgDown)

-what one non-IT workmate told me that it's annoying that he cannot
press KeyUp to go to the last option.

Thanks, we are in touch here :-)

-- 
Carles Pina i Estany		GPG id: 0x8CBDAE64
	http://pinux.info	Manresa - Barcelona

Re: menu loop (patch)

[Robert Millan]

On Sat, Jul 19, 2008 at 07:21:34PM +0200, Carles Pina i Estany wrote:
> > I'm not sure if this is intentional.  Size is not important in this
> > part of the code, but in other UI menus (e.g. Iceweasel or GNOME) I
> 
> fast check in KDE: it's looping
> 
> Also, Iceweasel menus are looping here (maybe because it's executed
> in KDE and there is some GTK Widget with a different behaviour? I have
> no idea)

I think it depends on the type of menu.  Iceweasel's stored password list
doesn't loop, but pull-down menus do.  I'm not sure if there's a rationale
for this..

> > notice this is not done.  It could also be a nuissance for users who
> > want to go rapidly to the top or bottom (sure, they can use PgUp/PgDn,
> > but then aren't we making the behaviour of those keys inconsistent
> > with arrows?).
> 
> I would be glad to add some functionality for PgUp/PgDown and also for
> Home/End keys (I would do it today evening or tomorrow and send the
> patch).

Actually, I just noticed we don't handle any of these.  Don't worry about
that.

> > Also, if you (or anyone) can point to a "usability best practices"
> > reference saying this has been carefuly analized and one of the
> > options was found to be better, I think this would help us make a
> > decision.
> 
> I will also check tonight.

Good!

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: menu loop (patch)

[Carles Pina i Estany]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]


Hi,

On Jul/19/2008, Robert Millan wrote:
> On Sat, Jul 19, 2008 at 07:21:34PM +0200, Carles Pina i Estany wrote:
> > > I'm not sure if this is intentional.  Size is not important in this
> > > part of the code, but in other UI menus (e.g. Iceweasel or GNOME) I
> > 
> > fast check in KDE: it's looping
> > 
> > Also, Iceweasel menus are looping here (maybe because it's executed
> > in KDE and there is some GTK Widget with a different behaviour? I have
> > no idea)
> 
> I think it depends on the type of menu.  Iceweasel's stored password list
> doesn't loop, but pull-down menus do.  I'm not sure if there's a rationale
> for this..

I have searched but I haven't found any UI guidelines talking about it.
And as you said, it depends of the kind of the menu (menu like menu or
stored password list).

I will keep searching/asking but I'm not sure if I will find something
conclusive.

> > > notice this is not done.  It could also be a nuissance for users who
> > > want to go rapidly to the top or bottom (sure, they can use PgUp/PgDn,
> > > but then aren't we making the behaviour of those keys inconsistent
> > > with arrows?).
> > 
> > I would be glad to add some functionality for PgUp/PgDown and also for
> > Home/End keys (I would do it today evening or tomorrow and send the
> > patch).
> 
> Actually, I just noticed we don't handle any of these.  Don't worry about
> that.

I've just had some minutes and I wanted to play with this (only Home and
End keys). I attach the patch, nothing important but fun.

If PgUp/PgDown is also wanted I will play with it (or somebody else).

(I agree that, nowadays and in laptops, Home and End keys are in some
unexpected places :-( )

Also, I would change the line 400 aprox. in file normal/menu.c:

            case 14:
by:
	    case GRUB_TERM_DOWN:
And case 16 by GRUB_TERM_UP

This is defined in include/grub/term.h

(I don't send a patch because is easy-easy and it's in the same zone
than previous patch)

Thanks,

-- 
Carles Pina i Estany		GPG id: 0x8CBDAE64
	http://pinux.info	Manresa - Barcelona

[-- Attachment #2: home_end.patch --]
[-- Type: text/x-diff, Size: 675 bytes --]

Index: normal/menu.c
===================================================================
--- normal/menu.c	(revision 1718)
+++ normal/menu.c	(working copy)
@@ -405,6 +405,22 @@
 	  
 	  switch (c)
 	    {
+            case GRUB_TERM_HOME:
+	       first=0;
+	       offset=0;
+	       print_entries (menu, first, offset);
+	       break;
+
+	    case GRUB_TERM_END:
+	      offset = menu->size - 1;
+	      if (offset > GRUB_TERM_NUM_ENTRIES - 1)
+		{
+                  first = offset - (GRUB_TERM_NUM_ENTRIES - 1);
+		  offset = GRUB_TERM_NUM_ENTRIES - 1;
+		}
+		print_entries (menu, first, offset);
+	      break;
+
 	    case 16:
 	    case '^':
 	      if (offset > 0)

Re: menu loop (patch)

[Isaac Dupree]

Carles Pina i Estany wrote:
> fast check in KDE: it's looping
> 
> Also, Iceweasel menus are looping here (maybe because it's executed
> in KDE and there is some GTK Widget with a different behaviour? I have
> no idea)

GTK menubar-menus are looping for me.  But I'm not sure about menus that 
consist of selecting from a list in a box (maybe some login window?).  I 
don't care personally, because my GRUB-lists are not terribly long... 
hmm, if you hold down a (arrow) key in GRUB, is there auto-repeat?

-Isaac

Re: menu loop (patch)

[Carles Pina i Estany]

Hello,

On Jul/19/2008, Isaac Dupree wrote:
> Carles Pina i Estany wrote:
>> fast check in KDE: it's looping
>>
>> Also, Iceweasel menus are looping here (maybe because it's executed
>> in KDE and there is some GTK Widget with a different behaviour? I have
>> no idea)
>
> GTK menubar-menus are looping for me.  But I'm not sure about menus that  
> consist of selecting from a list in a box (maybe some login window?).  I  
> don't care personally, because my GRUB-lists are not terribly long...  
> hmm, if you hold down a (arrow) key in GRUB, is there auto-repeat?

no, there isn't auto-repeat (this is what the patch that we are talking
does).

GRUB-lists shouldn't be terrible long, but quite users needs to go from
the first option to the last option quite often (at least is what i
see).

-- 
Carles Pina i Estany		GPG id: 0x8CBDAE64
	http://pinux.info	Manresa - Barcelona

Re: menu loop (patch)

[Isaac Dupree]

Carles Pina i Estany wrote:
> Hello,
> 
> On Jul/19/2008, Isaac Dupree wrote:
>> Carles Pina i Estany wrote:
>>> fast check in KDE: it's looping
>>>
>>> Also, Iceweasel menus are looping here (maybe because it's executed
>>> in KDE and there is some GTK Widget with a different behaviour? I have
>>> no idea)
>> GTK menubar-menus are looping for me.  But I'm not sure about menus that  
>> consist of selecting from a list in a box (maybe some login window?).  I  
>> don't care personally, because my GRUB-lists are not terribly long...  
>> hmm, if you hold down a (arrow) key in GRUB, is there auto-repeat?
> 
> no, there isn't auto-repeat (this is what the patch that we are talking
> does).
> 
> GRUB-lists shouldn't be terrible long, but quite users needs to go from
> the first option to the last option quite often (at least is what i
> see).

is this because tools tend to add options to the *end* of the list -- 
the same way my browser adds bookmarks to the end of the bookmarks menu? 
  That's the situation I find myself really using looping regularly in 
my OS (Firefox, Linux).

It might be worth the effort to add a config option, if there are people 
who have to deal with their boot-menu on a regular basis (are there? 
probably...).  Then if they're like me, they'll want to be able to fix 
its annoying behavior for the future.  So it's worth it for them; and if 
there are a significant number of people like that, the one-time cost of 
*implementing* the option may be worth it.

-Isaac

Re: menu loop (patch)

[Colin D Bennett]

On Sun, 20 Jul 2008 01:31:55 +0200
Carles Pina i Estany <carles@pina.cat> wrote:

> 
> Hello,
> 
> On Jul/19/2008, Isaac Dupree wrote:
> > Carles Pina i Estany wrote:
> >> fast check in KDE: it's looping
> >>
> >> Also, Iceweasel menus are looping here (maybe because it's executed
> >> in KDE and there is some GTK Widget with a different behaviour? I
> >> have no idea)
> >
> > GTK menubar-menus are looping for me.  But I'm not sure about menus
> > that consist of selecting from a list in a box (maybe some login
> > window?).  I don't care personally, because my GRUB-lists are not
> > terribly long... hmm, if you hold down a (arrow) key in GRUB, is
> > there auto-repeat?
> 
> no, there isn't auto-repeat (this is what the patch that we are
> talking does).

I think Isaac means: is there key-repeat functionality, and the answer
is yes; the BIOS int 16h key functions supply the key auto-repeat
functionality.  You are talking about "looping" around the menu when an
attempt is made to go past the beginning or end.

Regards,
Colin

Re: menu loop (patch)

[Colin D Bennett]

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

On Sat, 19 Jul 2008 17:40:43 +0200
Robert Millan <rmh@aybabtu.com> wrote:

> On Thu, Jul 17, 2008 at 11:22:27PM +0200, Carles Pina i Estany wrote:
> > 
> > Hello,
> 
> Carles!  Que n'és de petit el món ;-)
> 
> > I'm a Grub user (thanks for your nice work!) and I always wanted to
> > have a menu that "loops". Like, if you press down and you are in
> > the last option it goes to the first one, and if you press up but
> > you are int he first option goes to the last.
> > 
> > Attached comes a patch against revision 1718.
> > 
> > Of course, feel free to comment anything about it. I'm open to
> > change, fix, etc.
> > 
> > I also don't know if this functionality is not in Grub because you
> > thought that was better to not have this functionality. 
> > 
> > I've copied/change a few lines (after the patch, lines 425-428 are
> > the same than lines 347-350). I don't think that it's needed to
> > refactor but if you think so I can do it.
> 
> I'm not sure if this is intentional.  Size is not important in this
> part of the code, but in other UI menus (e.g. Iceweasel or GNOME) I
> notice this is not done.  It could also be a nuissance for users who
> want to go rapidly to the top or bottom (sure, they can use
> PgUp/PgDn, but then aren't we making the behaviour of those keys
> inconsistent with arrows?).
> 
> Also, if you (or anyone) can point to a "usability best practices"
> reference saying this has been carefuly analized and one of the
> options was found to be better, I think this would help us make a
> decision.
> 
> What does everyone else think?

I think that wrapping around the menu with the arrow keys *can* be
useful in some situations, but in general it seems like we should try
to be consistent with the common UI behavior that is expected, at least
by default.  We could support a setting such as "set menuwrap=1" which
would enable this feature for users who care about it.  Then the users
who don't care won't miss it, but the users who do care can still have
it by adding a single line to grub.cfg.

> Colin, does this affect your graphical menu work in some way?  I
> suppose the same situation applies the same way to the upcoming new
> menu.  Or perhaps this can be made more flexible and be toggled by
> some CSS magic?

This would be no problem at all; it's essentially identical to how the
text mode menu from normal.mod works.  It could go either way, and
certainly would be easy to make it a setting in the theme file (or more
likely in a user-configurable place such as grub.cfg (?) -- since we
might not expect most users to modify theme files but only choose which
one to use).

Actually my graphical menu currently *does* wrap around, I guess it
seemed logical to me at the time I wrote the code!  8-)  As you can
tell, I am not firmly set on either wrapping or not wrapping.

Regards,
Colin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: menu loop (patch)

[Robert Millan]

On Sat, Jul 19, 2008 at 10:34:46AM -0700, Colin D Bennett wrote:
> 
> [...]  We could support a setting such as "set menuwrap=1" which
> would enable this feature for users who care about it.

Isn't this a bit overkill?  The time spent adding this config option vastly
exceeds any time that could be saved by having or not having menu wrap.

> Actually my graphical menu currently *does* wrap around, I guess it
> seemed logical to me at the time I wrote the code!  8-)  As you can
> tell, I am not firmly set on either wrapping or not wrapping.

Same here..  my concern with taking arbitrary decisions is, when someone comes
later and asks to have it reverted, do we accept the request, and otherwise
what rationale do we give her? :-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: menu loop (patch)

[Yoshinori K. Okuji]

On Saturday 19 July 2008 21:58:09 Robert Millan wrote:
> On Sat, Jul 19, 2008 at 10:34:46AM -0700, Colin D Bennett wrote:
> > [...]  We could support a setting such as "set menuwrap=1" which
> > would enable this feature for users who care about it.
>
> Isn't this a bit overkill?  The time spent adding this config option vastly
> exceeds any time that could be saved by having or not having menu wrap.
>
> > Actually my graphical menu currently *does* wrap around, I guess it
> > seemed logical to me at the time I wrote the code!  8-)  As you can
> > tell, I am not firmly set on either wrapping or not wrapping.
>
> Same here..  my concern with taking arbitrary decisions is, when someone
> comes later and asks to have it reverted, do we accept the request, and
> otherwise what rationale do we give her? :-)

Personally, I prefer no wrapping, because it is easier for me to use only 
Up/Down arrow keys, yet locate entries easily. Since I am lazy, I don't want 
to look for Home or End (some keyboards really suck for them!), so when I 
just want to jump to somewhere near to the end, I only keep pushing Down, and 
wait for the cursor to stop. And, this is consistent with Dired mode in 
Emacs, Directory Listing in VIM, and, of course, with GRUB Legacy.

Regards,
Okuji

Re: menu loop (patch)

[Carles Pina i Estany]

Hello,

On Jul/19/2008, Colin D Bennett wrote:
> On Sat, 19 Jul 2008 17:40:43 +0200
> Robert Millan <rmh@aybabtu.com> wrote:
> 
> > On Thu, Jul 17, 2008 at 11:22:27PM +0200, Carles Pina i Estany wrote:

> > > I'm a Grub user (thanks for your nice work!) and I always wanted to
> > > have a menu that "loops". Like, if you press down and you are in
> > > the last option it goes to the first one, and if you press up but
> > > you are int he first option goes to the last.

[...]

> > What does everyone else think?
> 
> I think that wrapping around the menu with the arrow keys *can* be
> useful in some situations, but in general it seems like we should try
> to be consistent with the common UI behavior that is expected, at
> least by default.  We could support a setting such as "set menuwrap=1"
> which would enable this feature for users who care about it.  Then the
> users who don't care won't miss it, but the users who do care can
> still have it by adding a single line to grub.cfg.

in one way, add an options for this looks a bit like "overkill" (as
Robert said). In the other hand, I have my hopes that distributions
would like it and (mainly) all of them would add this option by default
:-) so could be a nice way to know what some people think.

> > Colin, does this affect your graphical menu work in some way?  I
> > suppose the same situation applies the same way to the upcoming new
> > menu.  Or perhaps this can be made more flexible and be toggled by
> > some CSS magic?
> 
> This would be no problem at all; it's essentially identical to how the
> text mode menu from normal.mod works.  It could go either way, and
> certainly would be easy to make it a setting in the theme file (or more
> likely in a user-configurable place such as grub.cfg (?) -- since we
> might not expect most users to modify theme files but only choose which
> one to use).
> 
> Actually my graphical menu currently *does* wrap around, I guess it

I'm new in this list and in Grub2 (I hvae not used, actually). Are you
saying that there is some graphical menu that does wrap?
I've read some opinions here against wrapping, but if the graphical ones
do it, in my (non-experted) opinion would be nice to have the wrapping
in text and graphic.

> seemed logical to me at the time I wrote the code!  8-)  As you can
> tell, I am not firmly set on either wrapping or not wrapping.

my workmate wanted it, i wanted and I've spoke with my brother and he
really wanted. But maybe it's because brother-love :-) (this is not
proving anything, of course)

-- 
Carles Pina i Estany		GPG id: 0x8CBDAE64
	http://pinux.info	Manresa - Barcelona

Re: menu loop (patch)

[Robert Millan]

On Sun, Jul 20, 2008 at 12:06:40AM +0200, Carles Pina i Estany wrote:
> > 
> > This would be no problem at all; it's essentially identical to how the
> > text mode menu from normal.mod works.  It could go either way, and
> > certainly would be easy to make it a setting in the theme file (or more
> > likely in a user-configurable place such as grub.cfg (?) -- since we
> > might not expect most users to modify theme files but only choose which
> > one to use).
> > 
> > Actually my graphical menu currently *does* wrap around, I guess it
> 
> I'm new in this list and in Grub2 (I hvae not used, actually). Are you
> saying that there is some graphical menu that does wrap?

Well, yes, but it's in a development branch (part of GSoC).

> > seemed logical to me at the time I wrote the code!  8-)  As you can
> > tell, I am not firmly set on either wrapping or not wrapping.
> 
> my workmate wanted it, i wanted and I've spoke with my brother and he
> really wanted. But maybe it's because brother-love :-) (this is not
> proving anything, of course)

Okuji doesn't seem to like it (see his other mail).  If you want to provide
some convincing arguments, I'd suggest finding a strong reference from
usability experts backing up your proposal.

The rest of us don't seem to care much either way (at least I don't).

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: menu loop (patch)

[Colin D Bennett]

On Sun, 20 Jul 2008 00:06:40 +0200
Carles Pina i Estany <carles@pina.cat> wrote:

> 
> Hello,
> 
> On Jul/19/2008, Colin D Bennett wrote:
> > On Sat, 19 Jul 2008 17:40:43 +0200
> > Robert Millan <rmh@aybabtu.com> wrote:
> > 
> > > On Thu, Jul 17, 2008 at 11:22:27PM +0200, Carles Pina i Estany
> > > wrote:
> 
> > > > I'm a Grub user (thanks for your nice work!) and I always
> > > > wanted to have a menu that "loops". Like, if you press down and
> > > > you are in the last option it goes to the first one, and if you
> > > > press up but you are int he first option goes to the last.
> 
> [...]
> 
> > > What does everyone else think?
> > 
> > I think that wrapping around the menu with the arrow keys *can* be
> > useful in some situations, but in general it seems like we should
> > try to be consistent with the common UI behavior that is expected,
> > at least by default.  We could support a setting such as "set
> > menuwrap=1" which would enable this feature for users who care
> > about it.  Then the users who don't care won't miss it, but the
> > users who do care can still have it by adding a single line to
> > grub.cfg.
> 
> in one way, add an options for this looks a bit like "overkill" (as
> Robert said). In the other hand, I have my hopes that distributions
> would like it and (mainly) all of them would add this option by
> default :-) so could be a nice way to know what some people think.

I agree it is probably not worth creating an option for.  It is
probably best to just decide to wrap or not to wrap... "that is the
question"  ;-)

> > > Colin, does this affect your graphical menu work in some way?  I
> > > suppose the same situation applies the same way to the upcoming
> > > new menu.  Or perhaps this can be made more flexible and be
> > > toggled by some CSS magic?
> > 
> > This would be no problem at all; it's essentially identical to how
> > the text mode menu from normal.mod works.  It could go either way,
> > and certainly would be easy to make it a setting in the theme file
> > (or more likely in a user-configurable place such as grub.cfg (?)
> > -- since we might not expect most users to modify theme files but
> > only choose which one to use).
> > 
> > Actually my graphical menu currently *does* wrap around, I guess it
> 
> I'm new in this list and in Grub2 (I hvae not used, actually). Are you
> saying that there is some graphical menu that does wrap?

I'm working on a graphical menu system for the Google Summer of Code
2008.  You can find out more about it at:
 
  http://grub.gibibit.com/Journal

It's not in the GRUB codebase yet, but it under heavy development.

> > seemed logical to me at the time I wrote the code!  8-)  As you can
> > tell, I am not firmly set on either wrapping or not wrapping.
> 
> my workmate wanted it, i wanted and I've spoke with my brother and he
> really wanted. But maybe it's because brother-love :-) (this is not
> proving anything, of course)

I'm fine with either option -- I'll just make it consistent with
whatever the core GRUB developers agree on.

Regards,
Colin