2009/3/9 Viktor Griph <[email protected]>: > I think it would be great if fvwm could apply as a mentoring organization in > this year's GSOC. I would be interested in working as a student on fvwm if > anyone has the time to mentor me. This will most likely be the last summer > I'll be eligible to participate as a student, and I'd really like to work > with fvwm full time this summer.
I'll jump at this in that I'd love to participate also, but not as a student; I am not one anymore. But I certainly have the time. > There are several items that can be added to an ideas list for fvwm. Here > are just a few ideas from the top of my head. Some need refinement, and some > are probably not good at all. > > * 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. > * 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. > * help finalizing fvwm 2.6 > - write a fvwm-convert-2.6 script This is something I've already done; just not made any noise about it yet. > - 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. > * add support for RANDR This is a good one actually -- and worthwhile. > * add support for some other XExtention/library > > * 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.) > 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. -- Thomas Adam
