On Fri, Mar 15, 2002 at 11:51:33AM +0000, Mikhael Goikhman wrote: > On 14 Mar 2002 11:08:50 -0500, Daniel Henninger wrote: > > > > > > Here is the very same patch from yesterday, applied to todays snapshot. > > > > It's behaving itself so far. =) > > > > > > I don't think that escaping a literal "~" with "~" is right. How would you > > > specify a grayed item starting with a literal "~" then? I suggest to > > > escape it with backslash (in fvwmrc file it is double backslash) - "\\~". > > > So a leading backslash may always be ignored in menu items. This way it is > > > possible to add more specifiers with a special meaning at the start. > > > > I see your point. I've changed the patch around to make a > > "scanInitialFlag" function instead of scanForGreyed. The function probes > > the initial part of the string, up until it either hits a backslash or an > > alphanumeric character (or the end of the string), looking for "whatever > > flag you pass it". Hopefully that'll be helpful in the future if there > > are other flags that are added like this, and also so potentially it could > > have: > > [EMAIL PROTECTED] Menu Item With Four Different Flags > > > > Yeah, if a menu item starts with === or something, then it'll scan over > > the ='s as well, but I don't think that'll be all that big of a problem. > > Was just trying to prevent it from pointlessly going over the whole > > string. > > > > Does this sound like a better option? > > Maybe, if we would not have to keep backward compatibility. > This is a bit too much to ask from a user. It should just test against all > valid specifiers, instead of ignoring all non-alphanumeric chars. For > example I have several menu items like "->" or "<-". > > Ideally it should be done differently by specifying Greyed flag, not by > some ascii character in front of the string. I would like if we stop this > hacking that breaks things that are automated. I.e. all automatic menu > generation scripts should include the same escape engine that fvwm itself > uses to parse item strings. This is not good. > > I like this patch, but can we delay it until we solve the problem of > specifying more than one action for the menu item? This will make it > possible to specify "Grayed" option just like "CommandOnMouse 2" option.
How about dumping that whole screwed up method to specify options for individual menu items and doing it from scratch? E.g. NewAddToMenu menu_name item_name [(item_options)] ItemAction NewAddToMenu menu_name (menu_options) and + item_name [(item_options)] ItemAction + (menu_options) The item_options and menu_options are enclosed in parentheses and can be omitted. Menu options: DynamicPopupAction DynamicPopdownAction MissingSubmenuFunc SidePicture SideColor (did I forget anything?) Item options: Greyed Hotkey Picture The mini icons should stay parts of the labels because they are formatted like the text. The proposed syntax is almost completely compatible with the old. Only items that have a name enclosed in parentheses but no action or items that have an action beginning with a left parenthesis are interpreted differently. I can't hink of any reason why someone would want that. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
