Alternative applications menu subfolder display location

when i go to open a folder on the applications menu (say games) the folder contents will open off to the left as shown… but when i then go to open a subfolder within (say board games), it opens off to the right and is very hard to distinguish from the main menu.

instead i would like to have the expected behavior of it opening on the left as the first one did and continue like that as long as there are nested folders.

is there any why to change to this behavior, or at least change the background color of the 3rd menu so it stands out when overlapped with the 1st menu.

This is a known issue with the Qt library: when you open a sub-menu that doesn’t have enough room towards the end of the screen (right side if you’re in a left-to-right context, left side if you’re in a right-to-left context), then the menu opens on the opposite side. Then if you open a sub-menu of that - now it has room to the right of the last menu opened - so the new sub-menu goes towards the end side again.

I get this behavior all the time with the clipboard manager (with the “open menu in cursor position” global shortcut) - it is set to a very large history, and if I need to go to the second page of results, it opens to one side, then the next opens on the back side, then the next back to the right, and so on and so forth.

This issue is already reported in the Qt bug tracker , though it looks like it isn’t prioritized. Personally I do not think there’s a problem to be solved here, but if you think otherwise - feel free to create an account there and comment.

Wouldn’t say this is a qt “issue”. Always been like that. Use any given floating manager ( openbox or whatever) and you’ll get that same “real estate opportunistic” behaviour. There sometimes seems to be a little change though. For instance, JWM seems to “calculate” the free space a little different than, say, icewm. Think it has to do with taking in account menu overlap, x/y positioning etc.

it seems the problem is that when opening a menu, it has a bias toward opening to the right even if the initial menu opens to the left.

where it should assume whatever bias based on the initial opening…

  • if to the right then keep opening to the right (current behavior)
  • if to the left then keep opening to the left (desired behavior)

i will create an acct to add this comment to the bug report, hopefully that bumps up the priority.

this example makes me question if the specific behavior i’m referring to is unique to the application menu

because in the first screen shot the menus bounce off the right edge and then keep going to the left, and that is what my example should do (the expected behavior) but it does not.

in my case it folds back on itself even tho there is no screen edge to bounce off of.

do another screen shot of the menu starting at the right edge of the screen so it has to bounce off on the first menu… doe it keep going to the left or does it fold back on itself for no reason?

As I mentioned in my comment - this behavior is not about the application menu - it is any menu implemented in Qt, and as @dzon mentioned - also in many other, possibly all other, toolkits.

If you can point at a menu system that “does it correctly” it would go a long way towards getting Qt people seriously interested in implementing this “consistent direction” that you prefer.

In floating wm’s there sometimes is an option as to set the offset of a submenu. Theoretically you could set it to a value with which submenus would kinda …um…cascade on top of eachother. A bit difficult to explain and I’ve never done it really. But imagine for a sec that the konsoles in the screenshot are submenus. They’d open on top of eachother in a vertical manner, not either left or right, but stacked. Still, that would require a setting as to cut the line (name) of a menu entry. A max width if you like.

@dzon has already shown it… the first screen shot shows a reversal of opening direction (3) that persists to the left (4) rather than defaulting to the right at every opportunity.

i don’t know how he did that, but however it happened, that is the behavior i would expect.

It’s not really “reverse the direction of all next sub-menus”. Simply that the 4th menu is a bit larger than the 2nd menu so it won’t fit to the right of the 3rd menu - so it goes to the left again. Measure the pixels and you’d see.

oh i see, then it still follows the bias of always opening to the right (or trying to) that is the issue.

i added my comment to the Qt bug report, we’ll see if anything comes of it.

fixed it… … … … … … … … … … … … …hackity hack hack hack