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: Changing menu in 0.9RC (24.02.06) (Read 6654 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Changing menu in 0.9RC (24.02.06)

I don't know if it's a bug or feature but after migrating to the latest RC from beta 10 I've found that I'm no longer able to edit the ''File-Edit-View'' menu elements.
I'd really liked this feature back as I prefer using my own menu structure.
Did I miss anything?

Changing menu in 0.9RC (24.02.06)

Reply #1 –
This feature has been dropped and won't come back. Here is a very good explanation from foosion.

Changing menu in 0.9RC (24.02.06)

Reply #2 –
Thanks, Ganymed. I've missed that topic on searching

Still completely disagree with the whole idea of creating uneditable menus because of the following reasons:
1. I've used a different scheme for quite a lot time. it has been tested on numerous users and they've found it being quite intuitive.
2. I'd still liked to have ability to clean the menu and slightly rearrange it.
3. IIRC very few users use Foobar "out of the box" and thus this might be considered being a lack of feature...
4. I just don't believe that automatical adding of new menu items cannot be done inside the "editable" scheme. Although it might require using quite a different approach.
Still just my personal opinion.

Sad it's gone. I'm about to roll back to old beta

Changing menu in 0.9RC (24.02.06)

Reply #3 –
Quote
4. I just don't believe that automatical adding of new menu items cannot be done inside the "editable" scheme. Although it might require using quite a different approach.[a href="index.php?act=findpost&pid=368838"][{POST_SNAPBACK}][/a]
Unfortunately, believes aren't worth anything when writing C++ code. If or when you find a constructive proof that it is possible, we'd like to hear about it though.

Quote
Sad it's gone. I'm about to roll back to old beta [a href="index.php?act=findpost&pid=368838"][{POST_SNAPBACK}][/a]
I just hope you are aware that the 0.9 SDK will not be compatible with the beta versions, and there will be no separate SDK for the beta version (which to us are obsolete).

Changing menu in 0.9RC (24.02.06)

Reply #4 –
Quote
Sad it's gone. I'm about to roll back to old beta
[a href="index.php?act=findpost&pid=368838"][{POST_SNAPBACK}][/a]


That sounds like a horrible idea. You are willing to use a beta build for the sole reason as to have the ability to edit menus? It just doesn't seem worth the:

1. trouble of dealing with a beta build
2. dealing with plugins designed for .9 that don't work

don't be stubborn, just accept the change. 

Changing menu in 0.9RC (24.02.06)

Reply #5 –
OK. Here's my basic solution.
It's probably not the best one, but hrere it is.

The main idea behind it is that might need to rearrange menu, rename/add/remove something but do this without turning FB2k menu into something completelly crazy.
I think that most people who need to rearrange menu do it because of the following reasons:
* they're vary familiar with their own menu scheme and they find it more ergonomic than the default one
* they need to add some commands to the menu because they feel better by accessing them from it, not using hotkeys or context menu
* they wish to remove certain items they find redundant in order to make the menus "lighter".

Let's take 09RC2 with just two groups: File and Playback as a sample.

[FILE]
Open
Open audio CD
---------------
Add files
Add directory
Add location
---------------
New Playlist
Load Playlist
Save Playlist
---------------
Preferences
--------------
Exit

[PLAYBACK]
Stop
Pause
....
Random
---------------
[order]>
Stop after current
Playback follows cursor
Cursor follows playback

Here's an example of a virtual [PLAY] group, replacing the ones above for a given John Doe:
[PLAY]
Open files
Add files
Add directory
---------------
[Playback order]>...
---------------
[Curor]>Playback follows cursor/Cursor follows playback
---------------
Load playlist
Save Playlist

What do we doe here:
* rearrange menus
* added/removed separators
* created new groups

At the same time we consider there might be plug-ins which add certain elements to the menu and they need to know where to add them in the customized menu.

Now let's try to redraw the very first two groups as:
[FILE]
[open]Open
[open]Open audio CD
---------------
[add]Add files
[add]Add directory
[add]Add location
---------------
[playlist]New Playlist
[playlist]Load Playlist
[playlist]Save Playlist
---------------
Preferences
--------------
Exit

Here we have splitted the menu into additional groups: open/add/playlist

Now do the same with the other group:

PLAYBACK]
[tracknavi]Stop
[tracknavi]Pause
[tracknavi]....
[tracknavi]Random
---------------
[order]>
[playbackmiscopt]Stop after current
[playbackmiscopt]Playback follows cursor
[playbackmiscopt]Cursor follows playback

same here: tacknavi/playbackmiscopt (I'd not liked to see these "names" implemented, they're just for sample)

Now let's try to solve person/machine (plug-in) compromise.

Machine needs: clearly defined structure, groups in order to know where to place certain items to
Person needs: more human-readable menu structure, better if its fits his own needs, he might also wish the plug-ins not being able to "spoil" his carefully created menu structure, but at the same time he might need certain groups being up to the date.

let's define some basic rules:
* there's a limited number of predefined groups which can only exist in one place (for example, the predefined [play] group cannot be in 3 menus at once)
* elements inside the group can be rearranged
* groups can be renamed (given a different alias)
* groups can be removed forever (well, until not taken back by user)
* group items can be used separately

Now that's how we build the final "megamenu":
* Create a new group in the Root and name it Play
* remove two old groups (above)
* Insert item>Group>[open](from the list of predefined elements)
* Remove [open]Open audio CD item from the group. Still the group exists and consist of a single element!
* Insert item>group>[add]
* Remove "location" item
* add separator
* Insert item>group>[order], rename it to Playback order. The group name is displayed as "Playback order (order)" in the editor.
* add separator
* insert item>group>new, name it cursor, insert a predefined group [playbackmiscopt] as a subgroup, rearrange
* insert separator
* do corresponding actions with the [playlist] group

and voila:
[PLAY]
Open files
Add files
Add directory
---------------
[Playback order]>...
---------------
[Curor]>Playback follows cursor/Cursor follows playback
---------------
Load playlist
Save Playlist

Now if a plug-in needs to find a prefedined [add] group, its place is obvious.

If a user doesn't want dynamic menus, he just recreates the menu structure out of standalone elements (or lock the menu otherwise)

P.S.: everyone is welcome to criticize/discuss/ignore this idea/suggestion. It's surely not ideal and or the ultimate truth.

Changing menu in 0.9RC (24.02.06)

Reply #6 –
Just wanted to know if the scheme above is worth writing few lines of C++ code...

Changing menu in 0.9RC (24.02.06)

Reply #7 –
Adapting yourself to something new will keep you somewhat active and flexible    - winding up in used patterns is mostly only useful in productive enviroments  - so give yourself a chance, boulet boy ...
 

Changing menu in 0.9RC (24.02.06)

Reply #8 –
Quote
let's define some basic rules:
* there's a limited number of predefined groups which can only exist in one place (for example, the predefined [play] group cannot be in 3 menus at once)
Why would you allow only a limited number of groups? Why not let a component define its own group for a set of commands that have a logical connection? (See Cut/Copy/Insert tracks in foo_utils.)
Quote
* elements inside the group can be rearranged
Where do you add new commands then so that the overall structure still makes sense? New commands can be introduced by installing a new component or a new version of an existing component.
Quote
* groups can be renamed (given a different alias)
What for? So components can no longer "find" them?

Changing menu in 0.9RC (24.02.06)

Reply #9 –
Ok, foosion, let me clarify it:

Quote
Why would you allow only a limited number of groups? Why not let a component define its own group for a set of commands that have a logical connection? (See Cut/Copy/Insert tracks in foo_utils.)

Well, having a limited number of basic groups (not needfully these are all possible groups!) gives you a kind os standartisation, so if a plug-in looks for a PLAY group, it might find one. Let's just call them "predefined" groups if it sounds better.

Quote
Where do you add new commands then so that the overall structure still makes sense? New commands can be introduced by installing a new component or a new version of an existing component.

the plug-in "knows" where to put commands to even if the menu is modified. For example, you have a predefined group [PLAY]: play/next/pause/stop. Then user removes "pause". Still the plug-in is able to use the group and insert items into it. Where to? The most basic solution is using the very bottom of the group. Surely, whis way it would be hard to place the "stop after current" between "next" and "pause" but my approach has some advantages too.

Quote
What for? So components can no longer "find" them?

Please, foosion, read the post more carefully. I'm referring to using aliases. I don't see how this may affect "finding" If someone "renames" [PLAY] to [DON'TPLAY], the plug-in is still able to find one by the old name: nothing shas changed for it. The [DON'TPLAY] is only needful for the end user and there are easy ways to inform him about the "former" name.

As you have been referrig to "solid" menus being needful in order to improve component interaction, I'm proposing a different scheme, which might be suitable for both programmers and end users.

Changing menu in 0.9RC (24.02.06)

Reply #10 –
Just wandering, foosion: is my solution adequate compromise?

Changing menu in 0.9RC (24.02.06)

Reply #11 –
Sorry, I haven't had much time during the last days to give this whole menu thing more thought.

Anyway, since there will only bugfixes until 0.9 final, the current scheme will stay at least until 0.9.1.

Changing menu in 0.9RC (24.02.06)

Reply #12 –
I know that no more features would be added to Foobar 0.9.
But if my solution is worth implementing I'd be happy to see it in any future version of the program.

Changing menu in 0.9RC (24.02.06)

Reply #13 –
I like the new menu structure, and I think people who are new to foobar2000 will have little problem using the application in that regard as it is similar to other Windows programs.
Although I think it's quite an improvement, when I add new components I get more menu items (well duh).  However, while these new components are useful in what I want them for, I may not need all of their features or I may use their features infrequently.

Basically what I am trying to say is that, as more menu items appear it slows down the process of finding what I want to do (as I have to search through all the other menu items).

I would prefer you guys to finalise 0.9 though, as this is only a minor thing to me. 

Changing menu in 0.9RC (24.02.06)

Reply #14 –
A hypothetical solution, would also be for less used options to auto-hide, or for submenus to be sorted by frequency of use...