m***@crosswire.com
2012-02-23 20:34:38 UTC
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 <***@fvwm.org>
Date: Thu, February 16, 2012 6:06 am
To: ***@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
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 <***@fvwm.org>
Date: Thu, February 16, 2012 6:06 am
To: ***@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