A scratch rewrite in C++, using WxWidgets and embedding the configuration elements in sqlite, killing configuration files for good and ever. There is a point at which you are doing yourself a favor by shooting the horse instead of feeding it.
Not trying to piss anyone off. IMHO, I'm just stating the obvious. There is more holding FVWM back than what can be fixed with debugging. Matt -------- Original Message -------- Subject: FVWM: GSoC 2012: Project ideas From: Thomas Adam <tho...@fvwm.org> Date: Thu, February 16, 2012 6:06 am To: fvwm@fvwm.org All, Whilst I appreciate that organisations need not worry about this until the end of February, I'll be moving house then so I need to start thinking about this now, rather than later. 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 This is a pre-requisite step for many other style-related project proposals though -- but still something which is a good enough project in its own right. * 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 ... where these styles are logically ANDed together, rather than ORed, to avoid the need for specific style-line ordering. * Unification of window commands/states to provide a consistent interface (Difficulty: Hard) Style (and WindowStyle) affect the state of windows, as well as specific commands which are not style-options but still affect the state of windows. There has long-since been an idea to unify this, and to split the entire concept into two states: - The initial state of windows (perhaps with an InitialState command) - Subsequent window operations happen with a WindowState command So you could think of this as FVWM commands at present which aren't style-related (but which operate on windows anyway) deprecated in that you have to set states of windows to have them work. Here's an example: # All windows' initial state are set like this. InitialWindowState * SetWindowState WindowShade E, Maximize 100 100 # I want to control "XTermA" to never windowshade. In setting this, as it's # already a running program, that specific window's state has changed, and # only that window. Next (XTermA) SetWindowState WindowShade Off # I want all XTerm windows to have a specific window state of iconified. InitialWindowState (Name=xterm,Class=XTerm) Iconify On Thus, all that happens in unifying the commands to properties on windows is a stack of things which are applied/unapplied as appropriate. This change is huge though, and would need more discussion. * Decor code to be modularised (Difficulty: Medium): Finally deprecated the decoration code as being in the core, and instead allow for this to be handled with a FvwmDecor module (or some such name). Some thought would need to be put in to how this is handled by modules, as there should be some means to allow more than one module to decorate a given window. This will require a change in libs/vpacket.h as well as the module information. * Allow fine-grained control of window decors (Difficulty: Hard): If we ever want to allow users to customise the colour and/or which parts of a decor is rendered, we need to rethink the FW_FRAME construct, and how that's rendered in terms of its current GC implementation. A module would need to do this -- as well as defaulting to a base decor (such as a MWM look?) Shape-masking might be a possible to do this. This would also allow for bling features like rounded-corners. This is obviously the future now, where bling is more important than functionality. Comments welcome, or even ideas. -- Thomas Adam
