In the Song Editor, the gear icon should trigger context menu with RMB (not LMB)

[raindropsfromsky]

[EDIT]: Note that the proposed resolution is completely different. I am not changing my suggestion to match that; otherwise the subsequent posts in this thread will not make any sense.

In the Song Editor tracks, the gear icon is the only place where the context menu is triggered with LMB, rather with RMB. In fact, the RMB has no response at all.

On the same track, all the other elements have context menus triggered with RMB. (Mute+Solo LEDs, VOL, PAN, and elements on timeline)

Desired: Even the gear icon should have context menu, for the sake of consistency.

[tresf]

This is fairly common. In Firefox, for example, you can right-click the toolbar and have actions -- or -- left click the settings stack and have actions.

When a context menu has a dedicated button, you don't need a right-click trigger. It's a throwback to File, Edit, View. I do not consider this a bug.

[raindropsfromsky]

Well, in LMMS, there is a distinct difference between a "context menu" action list and the LMB actions.

For example, when we click with LMB, the LEDS turn on/off. The VOL/PAN knobs turn. The label pops up the instrument window.

Only the gear icon does exactly with LMB what the other things do with RMB. So why have this exception, if there are no other constraints?

[raindropsfromsky]

The only notable exception is Blender, where the object is selected with RMB, instead of LMB. And this is purposefully done. Not so in LMMS.

[tresf]

Only the gear icon does exactly with LMB what the other things do with RMB. So why have this exception, if there are no other constraints?

Because the gear otherwise has no other action. The gear is a popup trigger and actions can be popup triggers. This is exactly how popup triggers work inside a UI.

An example of a popup-trigger with left-click in LMMS is a combo box, as can be observed in the Zoom dropdown. The popup for zoom is the primary action. Secondary-actions such as reset, copy, paste will show in a combo box if right-clicked. It's not often that a menu is used for a primary action, but it's also not uncommon nor nonstandard or even clunky to use. The gear is supposed to do this.

To switch to right-click would actually be inconsistent. We plan on moving the File, Edit, View to a similar UI element.

For reference to the "File, Edit, View" plan: https://github.com/LMMS/lmms/issues/387

The argument can be made that right-clicking an empty area should trigger the same context menu, but that's an enhancement... argurably one that would take less time to code than it would to argue on this tracker. ;)

I do not see a valid argument for making the gear respond to right-click.

[raindropsfromsky]

Well, plan #387 actually mentions a button that looks like the Android "Action overflow" (aka "Menu") button, which always works with LMB.

So that is not an example of how LMB is used as an exception.

Let me try to put this visually: Within a space of 2 inches, we have three menu lists: They look identical. If we ask LMMS users to take a blind test, and tell us which button should trigger each menu. How would they respond?

[Spekular]

What part of "identical" means that the track actions menu doesn't have a label at the top while the others do?

Besides, the menu only appears once you've triggered it. What's more relevant is the element being clicked to summon this menu. A giant gear icon does not say "right click" to me. The mute button and volume controls both already have obvious primary functions used with LMB, so naturally the menu would have to be RMB

RMB isn't a dedicated "context menu" button. If anything it's a dedicated "secondary action" button, and context menus happen to be a common secondary action. Opening the track controls isn't a secondary action of the gear icon.

On Tue, Mar 6, 2018, 03:37 Narayan notifications@github.com wrote:

Well, plan #387 https://github.com/LMMS/lmms/issues/387 actually mentions a button that looks like the Android "Action overflow" (aka "Menu") button, which always works with LMB.

So that is not an example of how LMB is used as an exception.

Let me try to put this visually: Within a space of 2 inches, we have three menu lists: [image: image] https://user-images.githubusercontent.com/9047168/37011232-3f708ed8-2115-11e8-99a2-b1e3775e4087.png They look identical. If we ask LMMS users to take a blind test, and tell us which button should trigger each menu. How would they respond?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/4217#issuecomment-370641491, or mute the thread https://github.com/notifications/unsubscribe-auth/AIgVmnrghIYk0dcAcCDEs6u2kd4UmIKnks5tbfZOgaJpZM4Scsso .

[raindropsfromsky]

I wrote "identical" to mean that the three lists contain very similar actions. They are not distinguishable which list is fit for LMB and which is fit for RMB.

A label is not relevant for a context menu at all. In fact, most other apps do not have a label in the context menu. So we should not differentiate between lists based on whether they have a label.

Secondly, the size of the target feature is not indicative of whether it can have a context menu. For example, the Time Signature and Tempo panel in the main window are even larger than the gear icon. They have context menus.

The Note velocity area in the Piano Roll Editor is much larger, and yet has a context menu.

Finally, usually gear buttons trigger the settings dialog with a LMB click; and do not usually have a context menu. But here it is not used for that purpose either.

[tresf]

They look identical.

We'd be happy to accept UI improvements to reduce confusion.

Do you think the UI would be less confusing if it were just a blank area with a right-click trigger? I do agree that the duplicate/delete operators are closer to what we'd see in a right-click menu from a consistency perspective, but then the quick-assignment operators makes more sense in the gear. How would you propose these actions are delivered that can get this bug closed?

[raindropsfromsky]

Do you think the UI would be less confusing if it were just a blank area with a right-click trigger?

IMHO the best way is to have the same action list, but triggered with RMB.

As regards the gear icon, it universally means "settings". So I do not know if so many settings icons are good to have in a single GUI. Maybe the overflow/menu icon is better. (?)

[tresf]

Maybe the overflow/menu icon image is better. (?) [...] triggered with RMB.

plan #387 actually mentions a button that looks like the Android "Action overflow" (aka "Menu") button, which always works with LMB.

So which is it?

[raindropsfromsky]

IMHO use the overflow/menu icon instead of gear That's it. Since LMB is always used with the Menu button, the current scheme will work just fine.

[Spekular]

The hamburger menu has the unfortunate side effect of looking a bit like a grab handle, though.

On Tue, Mar 6, 2018, 14:46 Narayan notifications@github.com wrote:

IMHO use the overflow/menu icon instead of gear [image: image] https://user-images.githubusercontent.com/9047168/37035413-7f2597aa-2172-11e8-8a44-aea42b0de62d.png That's it. Since LMB is always used with the Menu button, the current scheme will work just fine.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/4217#issuecomment-370785849, or mute the thread https://github.com/notifications/unsubscribe-auth/AIgVmref-c7_h56sTTZtnTfkXcN2FlmMks5tbpNJgaJpZM4Scsso .

[Spekular]

This also doesn't "fix" the issue of LMB vs RMB. If LMB is ok with the hamburger icon, I can't see why it wouldn't be ok with the cogwheel.

[raindropsfromsky]

Yes, both work with LMB, but-

• The gear wheel universally means settings (typically program setting).
• The menu button provides action items.

Therefore the menu icon is more appropriate.

The "LMB vs RMB" issue melts away because this icon is supposed to work with LMB.

[raindropsfromsky]

In the grab handle, the lines are more closely spaced, and the middle line is longer. (not sure if it has FOUR lines instead of three.)

[tresf]

Since the "Hamburger" mockup was proposed, Google Chrome has switched to the following:

Perhaps this could be a good compromise.

If LMB is ok with the hamburger icon, I can't see why it wouldn't be ok with the cogwheel.

This is 100% correct. The effort spent arguing this is a bikeshedding effort. Let's not waste any more time on this. @Umcaruje how do you feel about replacing the cog-wheel with an overflow-style menu indicator? (He's the one that worked with our designer to get our current theme implemented). Also please help us milestone this. It's a quick, cosmetic fix.

[Umcaruje]

I think the icon is not really the problem here, and changing the icon doesn't fix the problem.

The issue here is we have some non-standard behaviors of the elements. The track label button doesn't have a context menu, and the RMB behavior is to rename the track, which is non-standard behavior.

We also have the gear button which triggers the context menu which really belongs to the track label button, and it doesn't do anything when triggered by the RMB.

So the best way to fix this is to actually move the context menu to the track label button, make rename a part of the context menu, if a quick shortcut is still needed for rename we could do something like Ctrl + RMB.

This would probably make room for something like #2563 too.

Quick mockup:

As far as milestoning, it seems like a big change for 1.2 but I would personally vote against changing the icon, as I think the gear is a clearer icon than the three dots which really look similar to the track grip as @Spekular said.

[BaraMGB]

@Umcaruje that sounds like a plan. Rename also works by double click. I don't know if it's already implemented: when in rename mode [tab] could jump to the next track for renaming.

[tresf]

@raindropsfromsky can you please update the original bug report to clarify the new UI? (Gear removal, replace right-click rename behavior with context menu). This should be doable for 1.3.

[Umcaruje]

@tresf did you mean to tag @raindropsfromsky

[raindropsfromsky]

Should I change the description of the bug at the very top of the thread? Then the rest of the thread would look totally disconnected!

I like what @umcaruje proposed.

In fact, once the gear is removed, we have use the extra space to insert the channel number. (This shows the many-to-one relationship between instrument tracks and FX Mixer channel) (the channel number can be placed at the far right.)

[musikBear]

In fact, once the gear is removed, we have use the extra space to insert the channel number.

👍 -witch would be a great improvement!

[musikBear]

I went over this, and discovered a crinkle that is hard to explain, and also emphasize the need for some rehaul. I tried to 'pick' context at different positions, and then i got this Right-click position is marked yellow. I cant understand what this is for? What is currently '0' and what can be 'globally-automated' (btw properly the worst feature in lmms.. - and redundant too, unless MIDI import actually uses it(?) ) -if it in fact a context for the solo-diode?! That is my only 'guess', but for what use?

It is also 'weird' that there are 2 rename options. Double-click is known by everyone from folder renaming, so i suggest keeping that, and removing right-click.

I absolutely support using the realestate currently occupied by cogwheel, and adding a mixer-channel instead! Huge functional improvement. Right-clicking any-where would then open context-menu The ambiguous cogwheel could then be shelved.
And the (?) diode context should be removed as well, imo

---

Grrr... 😠 connect-to-controller.. That is not un-useable.. Darn..

[BaraMGB]

@musikBear thats the context menu for the LED button. you can automate this with a controller.

[musikBear]

@BaraMGB -yes i thought so much -hence my 😠 -I guess there need to be a rather extended area where that context is pulled from