On 02/17/2012 03:49 PM, 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.
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.
This new design would make that worse.
That was something I ran across years ago and saw it as thinking about a
slightly more versatile syntax, though it is the functionality in the
long run that is desired. I like how the idea was to give each menu item
a more detailed list of properties, to allow for a larger variety in
menu design. Such as being able to apply the different MenuStyles,
Actions, etc to an individual item as opposed to the whole menu. And I
think the current menu syntax is slightly limited in the ability to
allow the above in a nice way.
Though a slight modification of the current syntax to be more like
FvwmButtons (item1, item2, item3) as another option. Something like
AddToMenu MenuName (Item="xTerm",Hotkey="t",Action (Mouse 1) Exec xterm,
Action (Mouse 3) Exec xterm -g 80x60,Colorset=,Icon=,Frame=,etc)
The change of syntax was more along the thoughts of in order to improve
functionality an improved config syntax could go hand in hand. It was
just a suggestion, but after thomas mentioned that adding most (if not
all) the functionality is on the TODO list and not a large project,
there are plenty of other ideas to work with for GSoC.
jaimos
