On Fri, Feb 17, 2012 at 02:23:03AM -0500, MK wrote: > 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?
Yes. The point isn't to care about the structure but to show how it works at the moment. There is no grouping per-se of style options other than to say which letter that option begins with, which is only done that way to satisfy a switch statement. But a tree is overkill for this because all you're really doing is a linear search -- so having: struct style_opt_struct *all_style_ops[] Would be fine for this. > > * 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? No more so than Name, or Resource would be, yes. > > * 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? Absolutely it is a good idea. You can't keep using that as an excuse to disallow changes, and managing the migration wouldn't be too difficult. -- Thomas Adam
