On Thu, 16 Feb 2012 11:06:46 +0000 Thomas Adam <tho...@fvwm.org> wrote:
> Now that 2.6.0 is out, I'm proposing the following project (some of > which are a continuation from previous GSoC proposals) -- none of > which are listed in any order. > > * Style clean-up (Difficulty: Easy): > > This would involve thinking about the internal state of styles. At > the moment, we've a complete bomb-site in fvwm/styles.c in the form > of a huge case statement which is responsible for dishing out random > code to act on windows. I'd like to see this mechanism replaced with > something more like a dispatch-state, involving stucts and > callbacks. I've very tentatively started this here: > > https://github.com/ThomasAdam/fvwm/commits/ta/style-cmd-tweaks I think I get the gist of what you want to do there. Have you thought of using a hash table or tree in place of the a,b,c,d thing? I'll admit I don't use nearly everything fvwm has to offer, so forgive me if some of my next comments betray this ignorance ;) > * Finer-grained style matching (Difficulty: Medium): > > Currently there is no direct way to match specific components of > windows when putting styles to them -- the only way you can do this > at the moment is through clever ordering of style lines. This > project would therefore flesh out ideas to allow for specifiers for > which window to match based on a windows's name, class, resource, or > icon name. Perhaps in the form: > > Style (Name=xteddy,Class=XTeddy) Sticky Would "class" here be a new (optional) aspect of the fvwm syntax? > * Unification of window commands/states to provide a consistent > interface (Difficulty: Hard) > > This change is huge though, and would need more discussion. It implies to me a lot of drastic changes to the way the way the configuration is currently. Are you sure that is a good idea? MK -- "Enthusiasm is not the enemy of the intellect." (said of Irving Howe) "The angel of history[...]is turned toward the past." (Walter Benjamin)
