Thomas Adam
2012-02-16 11:06:46 UTC
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
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