Thomas Adam <tho...@fvwm.org> writes: > On Fri, Feb 17, 2012 at 05:49:00PM -0500, Dan Espen wrote: >> Thomas Adam <tho...@fvwm.org> writes: >> >> > On Fri, Feb 17, 2012 at 02:10:54PM -0700, Jaimos Skriletz wrote: >> >> > > 2) Rewrite the menu syntax and redsign the object, there was some talk >> >> > > about this on the mailing list years ago now and some good ideas for >> >> > >> >> > And the link to that thread is? >> >> > >> >> >> >> http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg07167.html >> > >> > Hmm. This is terrible. If only because menus are treated here as some >> > kind >> > of alien-citizen and if this suggestion was to ever go through they should >> > be treated the same way in FVWM like any other entity. >> >> Seems to be a lot of change with no new function. > > It's not that so much that. Menus are treated separately from functions -- > and in some respect they need to be, yet their syntax and operation can also > be similar. Moreso in that the way they're styled is separate from normal > windows (for technical reasons only). > > I don't deny that the feature-request for this is a good thing, but I do not > think gleaming anything from that thread in terms of its implementation > merits anything, especially not when comparing it to how menus are handled > now. > >> As I understand it, Fvwm can be accepting commands from many sources at >> the same time. Various modules can send commands to Fvwm, each is >> sent one at a time. I don't believe "+" is handled as it should be >> to account for this. > > Well there's no real way to send a "+" command from a module and its use > outside of a configuration file is going to be ambiguous and at best > completely undefined. And to be honest, that behaviour away from where "+" > is used *should* be that way. > > If there's a good enough case to demonstrate where the "+" command > falls-short, I'd entertain a bug-fix to this, but I would want to see some > test-cases to show how it's been fixed so as not to interrupt or break its > current behaviour, which works just fine.
A module (like FvwmCpp) could be reading user written config files and transforming them some way which would end up with Fvwm potentially getting "+" commands intermixed from multiple sources. I admit this is a stretch, no one has ever seen it but it remains possible. The solution would be to have the command stream's state stored for each input command stream. I'm not saying it's necessary to do that. It never occurs. Along similar lines, backslashes aren't accepted in most fvwm command streams like FvwmTalk. I think we want a design where Fvwm can perform a complete action each time it sees a command. It mostly does. Getting back to menus, Right now it's impossible to change or remove items in an existing menu, you can only destroy or add to the end. Tied in with this would be the ability to gray out menu entries. I think you can see how this would be useful. -- Dan Espen
