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

Menu layout changes in v1.0

Reply #100 –
Well, there was the question about constructive remarks... let's get it on.
First of all, I want to recall a few points said so far and ask a few questing: (and both sorry for quoting a bit and for the long post :-) )

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

Quote from: skyfish on
There are some actions I never use, and some actions I use often enough to curse when going through 3 levels. It feels like Microsoft's "create new briefcase here" context menu approach. Less headache for the devs, for sure.

Yes, that's the main issue with all us "advanced-users" here. Everyone of uses and loves foobar, but every mind is different. Everyone has his/her own "ways of using foobar". There'll never be a "golden way" how we expect a specific feature to work. (and imho, there don't has to be... having settings, even ones hidden in "advanced", to set things up as one wishes is awesome!)


Quote from: skyfish on
Peter and the guys must have had reason to remove the option. However, it simply ruined the context menu usability for the advanced half of the users.

Quote from: skyfish on
A foobar user is someone who is focused on the details strongly enough not to use a mainstream player. It is very natural that people get disappointed when a core feature gets removed.

And this sums it all up: While it may be easier for new users, it is likely to put long-time users off. In general I am in favour of asking: "What do we aim for?". However, speaking about an application with already so many settings (and I totally love them!), I am in for "why not make if optional?" (see remark below)

Now let me suggest a few possibilities (feel free to comment on them / criticise them as you like):
  • Make it optional
    Let there be an option to enable the re-arranging (or even to just revert to the old behaviour). There could easily be big lines advising users to have it switched off, or to switch it off before seeking help (or even just an hidden setting - within "Advanced" will do, won't it?).
    At least, this would target the "it is a support mess" concern.
  • Targeting the randomness
    Let plugins supply "standard position" consisting of an submenu and a location (like a priority - items are displayed sorted ascendingly; for example: "Add to playback queue" (90), "Play" (100), so a plugin could insert "Add to hotlist" (95) in between easily). This is the system we use over there, for miranda, and it remains undisputed as of yet. This would also give a "revert menu" option; even when using the "old behavior".
    This, also, addresses the "support mess" argument.
  • Let us choose
    Remove a disputed feature like this from the core (although it is essential, but this goes for foo_input_std and for some of us, foo_ccda, foo_utils, ... as well) and make it a plugin. This way, there will be (and in case noone else screams, you'd have a volunteer here) plugins imitating the more customizable approach or a way in between.


The devs said it was be too cumbersome to keep it and nobody uses it anyway. Especially after reading through this thread, I'd like to challenge the latter. And as for the first, well, nobody said you should have to bother with a bit of UI that has gotten more and more complicated while you want to focus on "core functionality" and stability. Nothing wrong with that! Leave the UI bits, the last bits to get this last speck of usability, to us. That's what a community like this is for!

Cheers,
Klaus

Menu layout changes in v1.0

Reply #101 –
Seems that now, nobody wants to comment on constructive remarks... Well, it's always easier to complain, I guess.

Menu layout changes in v1.0

Reply #102 –
This thread is not for constructive remarks — the devs made it clear they aren't looking for alternative suggestions. So this thread serves a purely therapeutic reason — to let off some steam, preferably in a form of a suggestion (it makes it sound slightly less pissed off).

You did it almost right, but your mistake was to expect a change outside yourself.

Menu layout changes in v1.0

Reply #103 –
Quote from: skyfish on
This thread is not for constructive remarks — the devs made it clear they aren't looking for alternative suggestions. So this thread serves a purely therapeutic reason — to let off some steam, preferably in a form of a suggestion (it makes it sound slightly less pissed off).

Sorry, i thought there where many times where it was suggested they where open to suggestions:

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


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


Quote from: Yirkha on
I personally think that if anything, an additional feature to "pin" a few most used, but maybe often deeply burried, items to the top of the menu, maybe in user-defined order, could be feasible. But rather only because I can see different people have different usage habits, I don't really know what I would put there.





Menu layout changes in v1.0

Reply #104 –
Quote from: skyfish on
the devs made it clear they aren't looking for alternative suggestions.
Which post by whom specifically are you referring to?
Full-quoting makes you scroll past the same junk over and over.

Menu layout changes in v1.0

Reply #105 –
Quote
It's not changing. Get used to it.
seems pretty unambiguous to me.

Menu layout changes in v1.0

Reply #106 –
Quote
It's not simply changing back. Get used to it.
Here, unambiguited it for 'ya.

Here's how it goes: Peter thinks to himself "Meh, the default context menu is still a wreck, I should have rewritten it in 0.9 already..." and comes up with something better both implementation and user experience-wise (yes, talking about the unverified majority of users who don't rearrange their menu). Now that's done, it really won't just come back as it was, get used to it. No hidden checkboxes with large warning messages or other nonsense either.

The point of this topic is to gather feedback and ideas and comments which might make him think "Hmm yeah, this actually might be annoying" or "there are quite a few users who..." or similar and do something about it. If nothing like that happened so far, the arguments probably weren't convincing enough, considering the number of affected users, added complexity (code and presented to the user) and other factors. Nevertheless all posts are read, writting "Yes, thank you for your comment" after each one wouldn't make difference. (But might stop useless bumping, yay. )
Full-quoting makes you scroll past the same junk over and over.

Menu layout changes in v1.0

Reply #107 –
Till yet I am using fb2k v1.0 beta 4 occasionally only (installed in portable mode).

Comparing its handling with my "main" version 0.9.6.9 I am coming again and again to the conclusion that the additional shift key to hold down for showing the main menu commands which are hidden by default slows down considerably my flow of work; I am using foobar2000 very intensively and several hours a day, at least 10 hours.

So I would like to ask for an option in Preferences to display again all main menu items without the need for pressing the shift key, an option which might be switched off by default. I dare to do that because Yirkha said:

Quote from: Yirkha on
The point of this topic is to gather feedback and ideas and comments which might make him think "Hmm yeah, this actually might be annoying" or "there are quite a few users who..."

Please excuse my bad English; unfortunately I am not able to express better what I am meaning.

This is HA. Not the Jerry Springer Show.

Menu layout changes in v1.0

Reply #108 –
Quote from: Yirkha on
The point of this topic is to gather feedback and ideas and comments which might make him think "Hmm yeah, this actually might be annoying" or "there are quite a few users who..." or similar and do something about it.


That's how I have always seen this thread. As far as I know, Peter has never commented in this thread himself nor has he ever commented on this topic in another thread. People are upset about the changes that have been made, but (and I'll try to word this properly without something coming out the wrong way) the great majority of us are not privy to the development roadmap. We don't know what lies in store for the context menu.

This may indeed be just the first step in context menu development. There may be something new in the unreleased API where it will automatically sort all plugins into a well-defined structure. Sure, everything is a mess now because so many plugins are in the legacy category so things are in context menu limbo till the new v1.0 API is released & the vast majority of available plugins will be considered legacy no longer. We, the general populace, simply do not know what the genius Peter has in store for us.

I'll try to word this differently in case there's any ambiguity in my words as I'd hate to be misinterpreted again.

Once upon a time there was a rather talented programmer named Peter who some considered to be brilliant. He worked on the Winamp team and he gained some notoriety by being quite vocal & releasing some Winamp plugins to improve audio quality. Time passed & Peter parted ways with the Winamp team. He then decided to release his own audio player and it was well-received because he had gained a reputation while working with Winamp for being a discerning person when it came to audio quality. Over time this new player, foobar2000, has become something drastically & radically better than what it was when the first version was originally released. This distinct improvement in quality wasn't accidental or by chance, but because hard decisions had to be made. They weren't always popular decisions, but they were always the right ones.

Foobar2000 and its user base are where they are now because of the faith that has been placed in the developers by the users. The devs have done a damn fine job in getting us to where we are now from where we started. It is now left to us, the users, to place our faith in the devs once again and believe that this is the right path to take with the context menu. They haven't let us down before. Why would they start now?

Let's all relax and see where v1.0 final gets us and what happens after the v1.0 API is released to developers. We have limited understanding of events now as we have a limited view of the situation and the facts. We should wait till all the facts have been presented before we pass judgement rather than complain about the journey before we reach the destination.

Sorry for the length....I sometimes get a little chatty when talking about something I'm passionate about.

Menu layout changes in v1.0

Reply #109 –
To all those of you complaining about how some context-menu entries are 3 clicks away: That's what keyboard shortcuts and toolbar buttons are for.

Edit: Every single one of my F-keys is bound to some action in foobar2000, and some even vary depending on various combinations of Ctrl, Alt, Shift.

Menu layout changes in v1.0

Reply #110 –
Quote from: Robertina on
...the additional shift key to hold down for showing the main menu commands which are hidden by default slows down considerably my flow of work.
Which main menu commands specifically? I honestly thought that what had been shown stayed shown, and only what had been hidden became possibly shown with the Shift key.
Full-quoting makes you scroll past the same junk over and over.

Menu layout changes in v1.0

Reply #111 –
For me personally the removal of the context menu customization option for the sake of inexperienced users convenience was more than just an option removal. It was a move from us, loyal control freaks who witnessed the very birth of the foobar towards the itunes audience. This is to explain (not to excuse) the mood.

kwanbis, Yirkha, the overall response to these complains was 'deal with it'. I don't think I was too wrong to say that a fountain of alternative suggestions on this matter is not something the devs are impatiently awaiting.

Canar, does your remark on shortcuts imply that there is no need for the context menu at all? If not, what does it imply?
...Plus, since you are using your keyboard much, what your first reaction would be to the news that you can't customize it anymore? Because it confuses new users and overloads the support? And then to my suggestion to use a context menu instead (because I do so)?

Peter, if you accidentally stumbled upon this unfortunate thread, we still love you. Have to curse a bit, you know, but it's just a pressure reflex.

P.S. (rereads) Canar, my tone is sarcastic, but without fighting notes. Just grumbling here, half-asleep. Menu.. schmenu.. shrtcts... ppl

Menu layout changes in v1.0

Reply #112 –
Shortcut keys make accessing the context-menu more convenient in the case of commonly-used actions. Note that shortcuts and toolbar buttons provide roughly the same degree of functionality. It'll never be taken away (there's no justifiable reason for it to be removed anyhow) so your hypothetical situation is not one I can readily comprehend.

0.9 saw the disappearance of main-menu customization. People whined then, but they got used to it. How many of you miss that feature? How many of you were even using foobar2000 then? No functionality is gone. Some menu items are a little more inconvenient unless you want to do something about the inconvenience beyond whining, which is certainly still an option.

Note that I have never said anything in this thread about confusing users or anything regarding support.

Menu layout changes in v1.0

Reply #113 –
Quote from: Canar on
0.9 saw the disappearance of main-menu customization.
The context menu would have been changed in the same way back then, if some people hadn't protested heavily during the closed tests - including me. If I had to make the same decision again, I would choose differently.

Menu layout changes in v1.0

Reply #114 –
After some actual usage, I think that the new menu is a good compromise between simplicity and customizability, and lacks only one relatively small feature already mentioned in this topic. With this enhancement, it would still be simple ("ordinary-user"-friendly), yet it would provide some more control (and order) for users with a lot of components that add items to context-menu.

The thing I'm talking about is:

The 3-state checkbox in Preferences -> Display -> Context menu:
  • The item is always visible.
  • The item is visible when holding SHIFT.
  • The item is never visible.
[/b]

I don't know how to provide arguments that would be "convincing enough" to implement this :] It's just that now, when I call "extended" menu, it is heavily cluttered, even though I don't have lots of components. And by "heavily cluttered", I mean it has more than 15 positions in the main entry

And I don't think that we (we = users) need "Yes, thank you for your comment" answers from developers after each suggestion. Definite statements like "Sorry, this is not going to be implemented. Period." would be much more helpful

Menu layout changes in v1.0

Reply #115 –
Canar, again, if shortcuts are more convenient — why there is a context menu at all? Why not to remove it completely and use foobar just like you do? I thought maybe because it is easier to, say, select from a list of 10 tagging scripts (which are now 3 levels down), but I sense that I'm somehow wrong again here.

My hypothetical question was not about the realism of the change, but about your possible reaction to a removal of a feature you constantly use. Followed by a 'good for me = good for you' kind of advice.

Menu layout changes in v1.0

Reply #116 –
realism of change - hypothetical questions.
Philosophy 101 is taught elsewhere. Could you possibly be more tedious.
I do believe everyone has a good grasp of your wants and desires.

Can we please, please, move on.

terry

Menu layout changes in v1.0

Reply #117 –
terry, I've posted 29 times in 2 years and donated like enough to cover the pressure I put on the server. Could you please watch your tongue.

KKaul, your original suggestions sound reasonable, but I wouldn't probably expect them to be implemented in the nearest future.

Menu layout changes in v1.0

Reply #118 –
Quote from: Canar on
0.9 saw the disappearance of main-menu customization. People whined then, but they got used to it. How many of you miss that feature?

If whining is what you understand of the expressed opinion of an important part of the project, the users, then yes - I'm also whining about the loss of some features. Count me to the part of the fb2k community, who likes a feature-rich AND customizable player. And yes, full main and context menu customization are nice to have.
Quote
How many of you were even using foobar2000 then? No functionality is gone.

What a strange question is this? We're all still living. Yes, as long as foobar is better ('better' from my pov) than iTunes, I'll use it.

Menu layout changes in v1.0

Reply #119 –
Quote from: mixcherry on
The 3-state checkbox in Preferences -> Display -> Context menu:
  • The item is never visible.
[/b]


Huge +1 on that. As well as for the some way to show extended menu without need to press shift  (context menu is there to use it with mouse, not keyboard, hey!), as proposed earlier by @mixcherry too!

A bit off topic, but it was mentioned earlier. Someone said that main menu also works with shift. So - would it be possible to also add same editor for the main menu (disabling some item that we rarely use)?

Menu layout changes in v1.0

Reply #120 –
Quote from: lwiczek on
Huge +1 on that.


I already suggested that earlier but please also see shakey snakes good argument against that feature here.

After some weeks of using the 1.0b version i must say that i get used with it: as a button user who can't remember too many hotkeys i still think that buttons that let popup submenus are a very useful feature. Let' say you use often foo_discogs wich commands are in third level: wouldn't it be nice to have a button that opens the correspondending submenu of the context menu?

In the current implementation (also concerning main menu) i only see one weak point: the context menus tagging submenu and mainmenus view and playback submenus become messier the more components you install - especially when hidden items are shown. It would be ideal to seperate them in more groups divided by seperators. If it is of interest i can explain it more detailed.


Menu layout changes in v1.0

Reply #121 –
Quote from: q-stankovic on
Quote from: lwiczek on
Huge +1 on that.


I already suggested that earlier but please also see shakey snakes good argument against that feature here.


Missed that one, sorry.
But - at the moment users still can asks about present functionality that they hidden and forgotten about it + forgotten about using shift (well, it's not that obvious shortcut even for the "power users" and it isn't mentioned in the most obvious place like "context menu editor"). Basically - if someone decides to permanently hide some functionality, most of the time, they are aware what they are doing. And even using a stronger punishment/implementing most difficult obstacles won't prevent "poor souls" from messing with the configuration and forgetting about it...
------------
Anyhow - topic -> my point exactly.

EDIT: Could someone could merge those to post?

Done.

Menu layout changes in v1.0

Reply #122 –
Quote from: lwiczek on
(context menu is there to use it with mouse, not keyboard, hey!)
Wrong, hey! As the name implies, the context menu is just a context-specific menu. It can be used with the mouse (open with right-click) or the keyboard (open with Shift+F10* or the special menu key if you have it). By the way, if you have neither a mouse nor the special menu key, you have a hard time opening the reduced version of the context menu at the moment! I understand that it would be nice, if you could open the extended context menu using only the mouse. There are two ways that come to my mind:
  • Right-click while holding the left mouse button. Fast (+) and easy to implement (+), but rather unconventional (-) and hard to discover (--).
  • Reduced menu that shows the remaining entries, if you click the special down-arrow entry at the bottom. Common practice and easy to discover (++), works with mouse and keyboard (+), but higher implementation effort (-) and slower to use, therefore annoying (-).

Menu layout changes in v1.0

Reply #123 –
Quote from: foosion on
Right-click while holding the left mouse button. Fast (+) and easy to implement (+), but rather unconventional (-) and hard to discover (--).

I like it! It is not harder to discover than current solution (just mention it in release notes). It is faster than my proposal of extended menu on holding right button for 500ms or so. It doesn't require additional buttons (down-array buttons). I like it.

Menu layout changes in v1.0

Reply #124 –
Quote
Wrong, hey! As the name implies, the context menu is just a context-specific menu. It can be used with the mouse (open with right-click) or the keyboard (open with Shift+F10* or the special menu key if you have it).


Computer GUI tends to be more mouses/point-centring leaving keyboard only to text input. Using keyboard you can fully operate foobar. This doesn't go well with mouse-only operation (darn SHIFT  ). I'm not saying that I doesn't have keyboard, I do. I often have left hand on keyboard and right hand on mouse, but mostly while browsing where there is almost constant need to type something. On the other hand while I use foobar I tend to use mostly mouse: point this, play, send track to browser... and need for reaching on the occasion in the search for the shift... well, it's not nice

But I love the idea:
Quote
Right-click while holding the left mouse button. Fast (+) and easy to implement (+), but rather unconventional (-) and hard to discover (--).

If someone use mouse-gestures (in browsers) they are already familiar with it (go back/forward, etc) so only unconventional in the case of context menu. Hard to discover? Same goes for SHIFT. While this might be very-obvious-system-behaviour (that not that many actually knows  ) it might be mentioned (as well as the SHIFT) in context menu editor - problem solved

What about customization of main menu in same form as context menu at the moment?

Btw. was thinking about the subject (mainly "Reduced menu that shows the remaining entries, if you click the special down-array entry at the bottom") and it went from... this arrow thingy was in older office suites (it annoyed me, always turned it off), then my thoughts went to "hmm... but MS allowed to customize menus/toolbars without limitations! and that wasn't any problems for users. Then my mind went to newer versions of office (2007) with ribbon that also forbid the customization and hello, thanks to kindness of MS I've been testing their new office 2010 and guess what? There is customization of ribbon interface!  Where the MS got the idea that strict ribbon wasn't that great to use, hmmm