Bug 5235 - Right arrow opens first submenu when nothing selected.
Status: REOPENED
Alias: None
Product: Openbox
Classification: Unclassified
Component: general
Version: unspecified
Hardware: PC Linux
: P1 enhancement
Assignee: Dana Jansens
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2011-09-15 03:39 EDT by Alexey Korop
Modified: 2011-09-19 17:43:34 EDT
1 user (show)

See Also:

Attachments
patch based on the http://git.icculus.org/?p=dana/openbox.git;a=snapshot;h=98b02c6b60bbde2a5db026b3ee3e6e6dc44d1a92 (1.05 KB, patch)
2011-09-15 03:39 EDT, Alexey Korop

Description Alexey Korop 2011-09-15 03:39:39 EDT 
Created attachment 2970 [details]
patch based on the http://git.icculus.org/?p=dana/openbox.git;a=snapshot;h=98b02c6b60bbde2a5db026b3ee3e6e6dc44d1a92

If the openbox menu called using the keyboard, and the first item of this menu is the normal item, then the first item is selected. However, if the first item - submenu, then no item will be selected. This strange behavior is by design (openbox/menu.c:473):

        if (!mouse) {
            /* select the first entry if it's not a submenu and we opened
             * the menu with the keyboard, and skip all headers */
            GList *it = frame->entries;
            while (it) {
                ObMenuEntryFrame *e = it->data;
                if (e->entry->type == OB_MENU_ENTRY_TYPE_NORMAL) {
                    menu_frame_select(frame, e, FALSE);
                    break;
                } else if (e->entry->type == OB_MENU_ENTRY_TYPE_SEPARATOR)
                    it = g_list_next(it);
                else
                    break;
            }


   This behavior is strange and inconvenient. I see no reason to submenu has not been chosen. Perhaps this vestige left over from the time when autoopening delay a submenu not applied when using the keyboard.
   
   I propose to replace this strange and complex piece of very simple:
   
           if (!mouse)
              menu_frame_select_next(frame);
Comment 1 Dana Jansens 2011-09-15 08:52:19 EDT 
The reason for this behaviour is that the submenu may be a pipe menu which may take an arbitrary amount of time to show itself.

We want to ensure that the menu appears quickly and so we don't open a submenu.

One option: open the submenu but not if it's a pipemenu.

I think that would seem even more inconsistent than how things work now though, don't you?

Mika thoughts ?
Comment 2 Mikachu 2011-09-15 11:59:22 EDT 
(In reply to comment #1)
> The reason for this behaviour is that the submenu may be a pipe menu which may
> take an arbitrary amount of time to show itself.
> 
> We want to ensure that the menu appears quickly and so we don't open a submenu.
> 
> One option: open the submenu but not if it's a pipemenu.
> 
> I think that would seem even more inconsistent than how things work now though,
> don't you?
> 
> Mika thoughts ?

I pretty much agree with that.
Comment 3 Dana Jansens 2011-09-16 00:00:48 EDT 
As pointed out on the mailing list, this could recursively mean a a giant mass of menus opening at once also.

It could open the first submenu as a special case, but then really nothing is selected still.

I'd like to keep things how they are, it's the least inconsistent in my opinion.
Comment 4 Dana Jansens 2011-09-16 00:10:38 EDT 
When you first open the menu it takes two keystrokes to get into the first submenu.  Selecting the submenu automatically is not what I want to do, so instead we can have the right arrow select and enter the submenu.
Comment 5 Alexey Korop 2011-09-19 17:43:34 EDT 
(In reply to comment #4)
> When you first open the menu it takes two keystrokes to get into the first
> submenu.  Selecting the submenu automatically is not what I want to do, so
> instead we can have the right arrow select and enter the submenu.

    Do not put out the fire with gasoline! The main problem here is a strange  openbox behavior, not the pressing an extra key. Do not add one more case of the strange behavior, please.
    I propose to close this topic and leave it as it was.