On Fri, 17 Feb 2012 09:45:07 +0000 Thomas Adam <tho...@fvwm.org> wrote:
> 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: > > > * 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. Fair enough. There are only a hundred or so of them anyway, and I presume that happens (mostly) at start-up. > > > * 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. Those are passed thru from xlib, correct? I did not realize fvwm used all that, I've only ever just used the name, but looking at the manpage I notice it does. So the idea here would be to allow combinations of properties rather than a single one? Something I've thought a few times -- it may already be possible, but I don't think so -- would be the ability to label windows in the fvwm Exec command and use those labels with Style. That would allow you to have two different possible styles set up for applications (eg, terminal emulators) that otherwise have identical X properties. > > > * 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. Fair enough again. It would not upset me particularly, and I suppose the rest of the user base could be more excited than ticked off. If you did get two people from GSOC, to what extent do you think these various tasks could be done concurrently? MK -- "Enthusiasm is not the enemy of the intellect." (said of Irving Howe) "The angel of history[...]is turned toward the past." (Walter Benjamin)
