On Mon, 9 Mar 2009, Thomas Adam wrote:
* style/state rewrite
- unify the syntax for styles and states of windows, and make all states
matchable with conditionals
This is *huge* -- not something I would recommend as an undertaking of GSOC.
You are probably right. I think that trying to combine this with the
matching against calss/reasource/name was the reason why the CVS branch on
that kind of died. That and a sudden increase in work load. It might be
possible to refine the task into several smaller tasks. Splitting the
stlye command into an InitialStyle and a State command, keeping Style
Wired a both of them for backwords compatibility, could maybe be more
doable task to start with, While adding matching on window states sould be
a different task.
* fine grained style matching.
- continue the work on the CVS branch with contaiing stlye matching by
reasource, class or name specified.
This is better -- and self-contained enough that it would be possible,
but bear in mind it's still a stop-gap measure for the much larger
ideals of applying styles, those styles having states (based on the
window) etc. Perhaps this could form one piece of that puzzle.
- update test cases
- fix bugs
I don't see there being sufficient work for a student to work on this
myself. I might be wrong though.
It's hard to say, but I think you are probably right. 2.6 isn't that far
away. The testcases need a big overhaul, which is boring work, but
probably not enough to occupy a student a full summer. (Even though it
probably would take a week just to figure out what changes that have been
done that have no tests, and then there is the question of writing the
tests for them.)
* move advanced decorations to a module
- add a style DecoratedByModule
- change to module interface to allow window decorations to be handled
by a module (Should be able to have more than one decor module
running, so there must be a way to control which windows are
decorated by which module.)
- move the deprecated decor stuff to a separate module
This needs a lot of discussion and is something I'd always planned to
see post 2.6 as I have a number of opinions/ideas on this myself.
(Changing the module communication is one *large* facet itself, and is
perhaps a separate task in its own right.)
Yes. This one really needs discussion, and it should probably be split
into smaller tasks. Just making it possible for a module to decorate a
window, with all wat is means for dealing with user interaction needs is
probably lare enough for a single task. Not having thought a lot about it
I can think of two ways to deal with it. Either the module is responsible
for sending commands when a user interacts with a button/frame in the
decor, or the module should provide fvwm with window ids for all
interactable components that are included in the decoration. The former
has the advantage of allowing decor modules to rethink the interaction
model, but it will pose problems on execting compex functions based on the
click on a decoration part. The latter has the advantage of leaving most
of the frane interaction code as it is, by having fvwm process the events
of the decoration parts, and also keeps the module communication at a
lower level.
Needless to say this one need lots of discussion, and design descitions,
and probable is hard to mentor.
I think that the primary focus should be on 2.6, but it does not hurt to to
have some ideas for post 2.6 in there as well. I'm most interested in
working on the two first points on the list, but would like to see 2.6
released this year, and there are still several things things to do.
The requisite for all of these useful suggestions you've outlined here
come at a price: no one here has really fleshed them out fully -- and
ideally, I'd like a proposal feature to have been mapped out in
sufficient enough detail for a prospective GSOC student such as
yourself, if only because it saves time; to introduce a topic and then
not know what it is really supposed to do is wasteful.
They were just ideas, all open for discussion. GSoC deadline for mentor
organization submissions is this Friday, and if fvwm should apply we need
a list of ideas. Might be tahat it only contains a few well defined ones,
but seeing the short timespan I thought I'd start some discussion.
Another possble addition to the list is:
* Add/change to communication channel of FvwmCommand.
- possible channels include a UNIX socket, ICE protocol
This is an isolated task, but I'm not sure of the size of it. If it's just
to change the FIFOs used today to a socket, then it probably isn't big
enough, but if it also is to add an alternative channel (i.e ICE) to allow
communication with FvwmCommand over X rather than on the machine running
fvwm.
/Viktor
