This is something I noticed a while back, but put aside fixing it since
it's not very severe, and I couldn't think of what the solution should
be.
The issue is that it is possible to create several menus with the same
name, the latest definition being used inplace of earlier definitions, but
the earlier definitions coming back to like when the menu is destroyed.
This is done by (ab)use of the menu specific sidepic feature:
AddToMenu looks for an existing menu matching the exact string given for
the menu name, but creates a menu whe the name has had the side pic
component removed. My initial thought of a solution was to just parse the
name, and rid it of the sidepick info when looking for what menu to add
to. But then I thought: "What would the user want by specifying a sidepic
when adding ot an existing menu?" I couls not answer that, and still
can't, that's why I start this thread. What should fvwm do in this case?
My thoughts were:
A. ignore the sidepic info and add to the original menu as if no sidepic
were specified
B. give an informative error to the user and do nothing
C. Combine A with B as a warning
D. A if the sidepic matches the one in the menu already else B
E. Set/change the sidepic of the menu to the sidepic specified and
continue
F. something else
I still don't know which of these options that is the "correct" solution.
Test case:
AddToMenu TestMenu "Foo" DestroyMenu TestMenu
AddToMenu [EMAIL PROTECTED]@ "Bar" DestroyMenu TestMenu
Menu TestMenu
Menu TestMenu
And another test case:
AddToMenu TestMenu@@some_image@@ "Foo" DestroyMenu [EMAIL PROTECTED]@
AddToMenu [EMAIL PROTECTED]@ "Bar" DestroyMenu [EMAIL PROTECTED]@
AddToMenu TestMenu@@some_image@@ "Baz" DestroyMenu [EMAIL PROTECTED]@
Menu [EMAIL PROTECTED]@
Menu [EMAIL PROTECTED]@
In the above test cases some_image may be replaced with an existing image,
but that is not required for the bug to be reproduced.
/Viktor
