On Mon, Aug 18, 2014 at 11:25:51AM -0400, Dan Espen wrote: > Dominik Vogt <dominik.v...@gmx.de> writes: > >> I just did something similar for a work project. > >> But I didn't have a lifetime, so I just implemented the table > >> driven parser for the commands I was dealing with at the time. > >> Since then I've gone back and added a few more commands. > > > > Well, at the moment it's too early to think about how a new parser > > should look like. First we need to find out what the current fvwm > > needs from a parser. Than we can think about replacing commands > > and streamlining the syntax. > > I've never been in favor of an incompatible change not backed up > by an automatic conversion program. But that's just me.
No, not just you, I'm not fond of breaking the existing fvwm syntax either. But on the other hand fvwm2 has really hit a brick wall in ways of extensibility. If all else fails, backwards compatibility can be provided as some kind of module or input filter. > I'm not looking to dump fvwm2. It works too well for me. It works perfectly for me too. But I wish it was easier to introduce new features, and I'm still dreaming about some kind of "database" approach to window configuration where you can just dump configuration into, e.g. specific to window id, resource pattern, class pattern, for all windows, for windows with certain properties etc. When a window needs information about it's style, a lookup in the database spits out the most specific style information for each style. This would be so much more configurable (and hence able to get funny applications under control) than that mess of the style logic we have now. But eventually, some features like decors or the icon choosing code are too broken to be replaced by something better that is yet compatible. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
