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 72727 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Menu layout changes in v1.0

Reply #50 –
Quote
Components are free to do either, just as before.


I know, but before one was able to put this mess in some sort of order...

Menu layout changes in v1.0

Reply #51 –
Before it was much more of "a mess" because entry order was randomized based on the order the components were loaded on first run. Install fb2k four different times and you'd have four different context menus, until you were forced to re-arranged them.
elevatorladylevitateme

Menu layout changes in v1.0

Reply #52 –
I know, but still - if you want more order just stick to that value and try not to allow to much (uncleanable now) mess -- is that too unreasonable to ask?

Menu layout changes in v1.0

Reply #53 –
Sooooo...
Could you suggest something that is less messy, rather than just complaining? You've more posts than anyone else in this thread and you've made it quite clear you're unhappy and think it is a mess, so now how about constructive feedback? Is that too unreasonable to ask?

To quote:
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.


Do you have some grand organizing principle other than dumping everything into either "Tagging" or "File Operations" categories?
elevatorladylevitateme

Menu layout changes in v1.0

Reply #54 –
1. If its possible to find common cathegory for plugins - put it in there (autor of foo_discogs wouldn mind putting his splendid tool into Tagging)
2. If it's not place it as a category in main context menu but without ability to place, lets take 5 item from one plugin into main menu (without sub-categorizing it into /name_of_plugin/items

What's more -- you could also "nicely" suggest developers to follow some guidelines (there are none ATM but it would be a good idea to create something like that, same goes for preferences which are a bit messy at some places...).

Quote
Do you have some grand organizing principle other than dumping everything into either "Tagging" or "File Operations" categories?


Don't see a problem with crating 4-6 main categories consisting similar functionalities. It was said earlier that reading is rather tiresome and slow while choosing menu item (therefore preferences at the bottom of the given menu). Therefore limiting number of items will speed up process of selecting things we want (if there is limited number of groups it's easier to discern them while looking just at the length of group name.

Another way -- place every plugin in /root/plugin name/plugin items without groups. This will also be consistent. For the moment we have some groups (tagging, fileops), some plugins in main menu (Converter, Playback statistics, and other) and some in their group (tho its understandable given the circumstances)

Menu layout changes in v1.0

Reply #55 –
Quote from: lwiczek on
Don't see a problem with crating 4-6 main categories consisting similar functionalities.
...
Another way -- place every plugin in /root/plugin name/plugin items without groups.

Well, how it is right now is pretty much a combination of your two methods. Tagging and Utilities are "categories" and everything else is by component. (Contrary to your insistence otherwise, File Operations only contains items from foo_fileops)

The only real exception is that the 2 queue commands, Properties and "Open containing folder" have their own positions, which is fine given their importance.


Personally, I think this is an OK situation given that "categories" are a generally decent idea but are not going to be able to categorize everything a third-party component might want to do.
elevatorladylevitateme

Menu layout changes in v1.0

Reply #56 –
While my butt doesn't hurt as Canar has experienced, it's kind of a step backwards as others have suggested. I can fully appreciate the old context menu being a support nightmare, and the countless posts that flooded the forum about it... After all, it was the most sophisticated part of the 128 page preferences dialog and would surely confuse winamp users.

Menu layout changes in v1.0

Reply #57 –
lwizek,

i think you overestimate your ideal of a perfect order. The main and important point is to have a quick overview and not what you like to have: a super logical order. So the most people wouldn't bother to see "discogs" in the root as it would be reachable quicklier.

Menu layout changes in v1.0

Reply #58 –
Can the Context Menu items be rearranged in 1.0 beta 1? I want to move "Text Tools" (foo_texttools) out from the "Utilities" sub menu.

Menu layout changes in v1.0

Reply #59 –
Quote from: q-stankovic on
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.

That is how i like them. My most used commands first.

Quote from: shakey_snake on
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.

Sorry, what you mean by that? I have no problem with the customizable menues,  i just don't understand how they can be a problem to anyone. At worst, a simple "reset menues" command should be enough.

Quote from: shakey_snake on
Before it was much more of "a mess" because entry order was randomized based on the order the components were loaded on first run. Install fb2k four different times and you'd have four different context menus, until you were forced to re-arranged them.

Sorry, maybe i'm missing something, but, shouldn't sort order be the default, unless changed manually?

Menu layout changes in v1.0

Reply #60 –
There was no "default" order before, and nothing to "reset" them to. That was half the problem.

The other half of the problem was that to expose commands that weren't in the context menu for whatever reason, you had to go into the preferences to add them. So if someone needed replayGain's "by folder" mode, they had to open the preferences and mess with things  in order to expose the functionality they needed.
Now they just have to hold shift when they click, and can then later add it to the normally visible menu if they so wish.
elevatorladylevitateme

Menu layout changes in v1.0

Reply #61 –
Does 1.0 with CUI also have this reduced functionality, or does it stay like it was in previous versions?

Menu layout changes in v1.0

Reply #62 –
The context menu is a core feature.
elevatorladylevitateme

Menu layout changes in v1.0

Reply #63 –
Quote from: Canar on
Ease-of-use. Context menu customizability added needless complexity and provided little-to-no benefit.


I don't think so.
Rearranging context menu means user can choose shortcut key.

At added to Queue track, It changes shortcut key in context menu, automatically shows Remove from Playback Queue in contextmenu.

This means normally if you want to execute Open Containing Folder then press {appkey}F  but, at queued track, should press {appkey}P
and other shortcut key also will be changed.

New convenient option, Shift+{appkey} can change most of shortcut key

Rearranging Context Menu can provide user with less complex shortcut key and chance of choosing shortcut key.

Customizing menu group can also solve problem that no assigning shortcut key automatically.

Plz make it easier to use...
Customizing menu can make it easier, not just complexity

Menu layout changes in v1.0

Reply #64 –
I belong to the group that likes customizability (is that spelled correctly?) and I was never intimidated by the preference screen. It's good to have all settings in one place.
However I understand we're at the mercy of the development team and must accept that. But please keep in mind that the users that don't complain about complexity or ask seldom for support might use the features that casual users don't care about.

So I will not ask to be able to have "rename" at the highest level (instead of under fileops) although it was more convenient    .
What is (even) more important to me is that the associated "shortcut letter in context menu" stays the same, no matter what items are applicable (or not shown) for the currently selected item. I routinely use things like rightclick-e to jump to the replaygain menu or rightclick-n for conversion menu. A quick check looks like that's how it is now (good). Previously I had to move commands up until this "shortcut letter" would stay constant.
edit example from jk007 shows I was wrong about this. 

However I really miss one thing, the "Properties (properties tab)" is gone. It can not even be assigned to a keyboard shortcut. It shows action not found now. I don't think it would be against the new philosophy to re-instate it (as default hidden item).
In theory, there is no difference between theory and practice. In practice there is.

Menu layout changes in v1.0

Reply #65 –
Quote from: GeSomeone on
What is (even) more important to me is that the associated "shortcut letter in context menu" stays the same, no matter what items are applicable (or not shown) for the currently selected item. I routinely use things like rightclick-e to jump to the replaygain menu or rightclick-n for conversion menu. A quick check looks like that's how it is now (good). Previously I had to move commands up until this "shortcut letter" would stay constant.
edit example from jk007 shows I was wrong about this.


oh....  I wanna say that want use Constant shortcut letter by rearranging context menu like your point...

Menu layout changes in v1.0

Reply #66 –
Quote from: GeSomeone on
However I really miss one thing, the "Properties (properties tab)" is gone. It can not even be assigned to a keyboard shortcut. It shows action not found now. I don't think it would be against the new philosophy to re-instate it (as default hidden item).


It's there. Assign a shortcut to [context]->Properties.
That's so plausible, I can't believe it.

Menu layout changes in v1.0

Reply #67 –
Quote from: shakey_snake on
There was no "default" order before, and nothing to "reset" them to. That was half the problem.

There is now. So, why don't do what is now being done, so there is a "default" menu structure, and allow advanced users to customize? Do you think it would still be a problem?

Another option could be keeping what is now being done, and having at the top, a "favorites" submenu, where we can add menus/commands we want.

Menu layout changes in v1.0

Reply #68 –
Quote from: kwanbis on
There is now. So, why don't do what is now being done, so there is a "default" menu structure, and allow advanced users to customize? Do you think it would still be a problem?
It would be unnecessarily complex and/or messy to implement.

Quote from: kwanbis on
Another option could be keeping what is now being done, and having at the top, a "favorites" submenu, where we can add menus/commands we want.
This was actively considered at one point but it was determined that the new implementation was better suited at exposing the less commonly used items.
elevatorladylevitateme

Menu layout changes in v1.0

Reply #69 –
Quote from: shakey_snake on
It would be unnecessarily complex and/or messy to implement.

Really? I thought the "rearrangement" code for 0.9.x could be used on 1.0. Didn't knew it was so different.

Quote from: shakey_snake on
This was actively considered at one point but it was determined that the new implementation was better suited at exposing the less commonly used items.

Problem is that "less commonly used" is a very subjective term. My most used actions, are my masstagger scripts. Then "get data from feedb", then rename files, and then replaygain scan and merge:


Menu layout changes in v1.0

Reply #70 –
Quote from: kwanbis on
Problem is that "less commonly used" is a very subjective term. My most used actions, are my masstagger scripts. Then "get data from feedb", then rename files, and then replaygain scan and merge:

Sure. That's why you can still, at your own discretion, hide the functionality you less commonly use.
elevatorladylevitateme

Menu layout changes in v1.0

Reply #71 –
That it is interesting. Is that what you where referring to about the SHIFT?

Moderation: Removed useless full quote of the preceding post.

Menu layout changes in v1.0

Reply #72 –
Are you telling me you've gone all week without reading the release notes posted here and here and now here:
Quote
Menu layout changes

A new Context Menu structure has been introduced along with a reworked context menu preferences page.

Holding down shift while opening a menu - with both context and main menu - will bring up menu commands that are normally hidden, so you no longer need to go through the preferences page to access obscure commands that are hidden by default.


?!?
elevatorladylevitateme

Menu layout changes in v1.0

Reply #73 –
Jeje, nice one. Would be trying it.

Moderation: Removed useless full quote of the preceding post.

Menu layout changes in v1.0

Reply #74 –
A configurable context menu doesn't nessesary mean that things get messy.
I think the reason the old way sucked was because it wasn't very user friendly (as in usability). For example it wasn't possible to create categories yourself, or rename anything. Also the super long list of items which one can add was really a bit too long and messy unless you knew what you were looking for.
So the shift+click thing really is great since it got rid of this. On the other hand the loss of the ability to re-arrange items hurts a bit.

Personally i think if there was a userfriendly and intuitive context menu editor, then there would be no problem. I'm not talking about the ability to add new commands or anything fancy, just the ability to re-arrange things via drag & drop, rename items and create/delete categories.