Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Menu layout changes in v1.0 (Read 72739 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Menu layout changes in v1.0

Reply #25 –
Quote
Seriously, it doesnt matter.


Wrong, it does... Don't know bout you, but I don't like context menu barely fitting on my 24" display...

Quote
File operations category is for foo_fileops commands only.


And Tagging is only for foo_freedb? oh, wait... there is a foo_masstagger too, what we shall do?! (cynicism intended...)
 

Menu layout changes in v1.0

Reply #26 –
"Open containing folder" is available even without File Operations, and is on its place to mimic Windows' "Open file location" in shell context menu.
Full-quoting makes you scroll past the same junk over and over.

Menu layout changes in v1.0

Reply #27 –
What to do?
How about understanding that you have already clearly stated your point.

You are on the side of having the context menu be more flexible.

Maybe a few more examples from you are in order 

terry

Menu layout changes in v1.0

Reply #28 –
Quote from: lwiczek on
Quote
Seriously, it doesnt matter.


Wrong, it does... Don't know bout you, but I don't like context menu barely fitting on my 24" display...

1. Wait for legacy components to be updated.
2. Start figuring out what can be hidden, given your usage patterns.

At first the new context menu might seem bewildering and/or limiting, but after a few months of use you definitely don't want to go back.

The old menu was a support burden and a major annoyance for new users.
Good riddance!
elevatorladylevitateme

Menu layout changes in v1.0

Reply #29 –
I've never customized the context menu much -- except, I think, move the Properties to the bottom, for consistency with almost every other application. But that's a long time ago, and I might be mistaken.

Menu layout changes in v1.0

Reply #30 –
Quote
1. Wait for legacy components to be updated.
2. Start figuring out what can be hidden, given your usage patterns.


I've alredy done *2*, just the two quirks I've mention left for the menu to be more-or-less like my old one
As for the *1* -- not counting on this happening soon, given that with time they tend to rather be dropped that updated...

Menu layout changes in v1.0

Reply #31 –
Re-organization of a menu breaks no-one's needs. If a context menu is not fast enough, nothing's stopping you from mapping it to a hotkey or a toolbar button (current bugs excepted).

Yes, we get it, you're all butt-hurt about how the new context menu changes break your customization. It's not changing. Get used to it. If you want to contribute meaningfully, give ways in which the default layout can be improved, but please don't be surprised when we shoot them down. It's nothing personal. Things are how they are for reasons, not to irritate the customizers among us.

Menu layout changes in v1.0

Reply #32 –
I like the new context (and main!) menu, esp. shift-click for "hidden" options. Would it be possible to add another way for showing those hidden menu items - ie. without having to use keyboard. Eg. they could appear after holding right (or left for main menu) mouse button for certain amount of time (say 0.5sec) instead of "clicking". Or there could be "Show more options" item at the bottom (or small button in the corner of the context menu).

Will those suggestions for "mouse-only" people be taken into consideration?

Menu layout changes in v1.0

Reply #33 –
IIRC, I believe that shift-click was chosen because that combo modifies menus in Windows (especially 7).
elevatorladylevitateme

Menu layout changes in v1.0

Reply #34 –
http://www.infoplease.com/dictionary/brewers/high-words.html

Quote from: shakey_snake on
IIRC, I believe that shift-click was chosen because that combo modifies menus in Windows (especially 7).

OK, I understand that. Nevertheless, I think there is no reason not to extend existing Windows "standard". I still hope that your answer does not mean definitive 'no' to my suggestion.

And I believe this small enhancement would not complicate the application very much, and even better - it would increase its simplicity (© Canar) (you know, using only one device - mouse, instead of two - mouse + keyboard ) It's all these small details that we love foobar2000 for, isn't it?

Menu layout changes in v1.0

Reply #35 –
@Developers
I'm sure foobar is better internally for all your hard word - for this I thank-you.

However why have you decided to reduce the customisation of the context menu. I want the ability to group commands and simplay move command up\down. This really is a backward step.

Menu layout changes in v1.0

Reply #36 –
and there goes my sorted by usage frequency context menu.
No, seriously, 1.0 is a solid improvement. But putting properties and replaygain - the most frequently used items - to the bottom... It is disappointing.

Menu layout changes in v1.0

Reply #37 –
> properties [...] to the bottom

Note on interfaces: The first and last item of a context menu are the fastest items, because the user does not have to read the item to identify them. Reading is a slow operation for the brain. (tangent: it's the same reason why icons are good and why I still hate that Firefox has no icons in its context menu, despite the large set of too-similar items in the middle)

What, exactly is the current context menu layout? I don't wish to install just yet; I tend to wait for stable releases, and the Screenshots page on fb2k.org hasn't been updated yet (assumedly because of V1's beta stage).


By the way, is there an immediate indication for the state of stop-after-current yet? Just about my only FB pet peeve.

Menu layout changes in v1.0

Reply #38 –


With shift:

Menu layout changes in v1.0

Reply #39 –
Quote from: shakey_snake on
The old menu was a support burden and a major annoyance for new users.
Good riddance!
It was also a annoaynce for old users (like me): I was used f.e. to restructure the commands of foo_utils into new and renamed groups and for each command i had to open again and again  the pop-up window with the list of commands. I can remember when 0.9 was released i was horrified but it didn't took much time to get used and to be eased to see that new fixed main menu was nicer than my custom one in 0.8

Quote from: Canar on
If you want to contribute meaningfully, give ways in which the default layout can be improved, but please don't be surprised when we shoot them down. It's nothing personal. Things are how they are for reasons, not to irritate the customizers among us.
Ok, here a suggestion for improvement! 

One improvement of the new context menu not mentioned so far: you can't change anymore the path of a command (means: placing one command from origin group into another custom group). That caused the irritating inconsistency that in some parts of the program (f.e. hotkey editor) the origin path was continued to be displayed. That can't happen anymore.
That is a solid base to repeat an old request i made 1-2 years ago:
The more buttons you have the more context menu items you can hide to keep overview in contextmenu. In that context wouldn't it be useful to add groups as button (you even wouldn't have to change button dialogue)? I mean following: i select in the the tree the group "Quick Tagger" and am able to add this as button - clicking this button then opens the submenu.

Menu layout changes in v1.0

Reply #41 –
I honestly didn't know it was a support burden, and i don't understand why also ... i also know that if i HAVE to, i would probably get used to not being able to reorder, but i also believe it is a STEP BACKWARD, and i would surely miss my customize menu:

Menu layout changes in v1.0

Reply #42 –
@kwanbis
Your screenshot shows strange things: Commands that should be displayed in the "tagging" or "utils" menu are shown in root of context menu. That doesn't happen for me. Try removing foo_menu_addons to see if it helps.

Quote from: shakey_snake on
Start figuring out what can be hidden, given your usage patterns.


Good advice! There are commands we use never, in rare cases or often. So here one constructive idea more: a third state for the menu items - show hidden, show always and show never. So you would rather hide some items that you otherwise would show always and you can keep context menu with hidden items also cleaner.

Menu layout changes in v1.0

Reply #43 –
Quote from: kwanbis on
I honestly didn't know it was a support burden, and i don't understand why also .
All you have to do is follow the link I already provided labeled "support burden", and click on and read some of those  threads.

Feigning ignorance isn't a great way to help yourself.


Quote from: q-stankovic on
So here one constructive idea more: a third state for the menu items - show hidden, show always and show never. So you would rather hide some items that you otherwise would show always and you can keep context menu with hidden items also cleaner.
That really causes one of the same problems as the old menu: People who need something that they've removed (old) or "hidden always" have to go into the preferences to add it back.

Also, user might need that thing that they've hidden always sometime in the future and come to the forums making a "feature request' to do something that is already possible. (great example)
elevatorladylevitateme

Menu layout changes in v1.0

Reply #44 –
I am not sure, if you understood me correctly. With "show never" i don't mean to remove the item from the tree but to have a special symbol in the checkbox.
Example: not checked means show never, checked means show always and (after clicking a checked checkbox) the special symbol  means show hidden.

"Ok, I understand now."

Menu layout changes in v1.0

Reply #45 –
Would it be possible (or, more accurately, does it have a prayer of actually happening) to at least add some kind of indicator to the 'legacy commands' menu operator of what component those commands belong to?

Menu layout changes in v1.0

Reply #46 –
Quote from: shakey_snake on
1. Wait for legacy components to be updated.
2. Start figuring out what can be hidden, given your usage patterns.

At first the new context menu might seem bewildering and/or limiting, but after a few months of use you definitely don't want to go back.

I must admit that I'm slowly getting used to the new context menu, but I want to support mixcherry's proposal about using the hidden entries without having to use keyboard.

Menu layout changes in v1.0

Reply #47 –
Ok, i tested the new beta with all my components - and what a suprise: It is not the mess i expected.

However, here two minor suggestions to improve the out-of-the-box layout:
  • 1. The "tagging" submenu is the only one that appears messy. It would make sense to seperate this submenu into two subgroups diveded by a seperator: one for tagging operations and one for commands/groups that retrieves data from the internet
  • 2. All third party components which add their menus to the root have own subgroup: it is just one seperator that makes overview a little bit friendlier

Menu layout changes in v1.0

Reply #48 –
Quote
1. The "tagging" submenu is the only one that appears messy. It would make sense to seperate this submenu into two subgroups diveded by a seperator: one for tagging operations and one for commands/groups that retrieves data from the internet


+1

Quote
2. All third party components which add their menus to the root have own subgroup: it is just one seperator that makes overview a little bit friendlier


I'd prefere that plugins add their menu entries into more logical categories their funcionality fits (i.e. discogs fits perfectly into tagging)

Menu layout changes in v1.0

Reply #49 –
Components are free to do either, just as before.
elevatorladylevitateme