2009/3/9 Viktor Griph <[email protected]>: > 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.
Yes -- there's two problems with InitWindowState: 1. There's large areas of code that would need rewriting. 2. It would change the syntax of one's .fvwm2rc. Point 2., is of sufficient consideration that it would mean post 2.6 -- of course there's nothing wrong with that, but it would need to be fleshed out to define what it might look like. Plus you have to have a way of making current FVWM builtins no longer standalone -- i.e., they now have an assumed window context. But then not every FVWM builtin is sufficient to operate like this, so you'd need to enumerate them also. (If that makes sense?) For example, I started to play around with this -- and have thus far: * Defined several new structs/enums to support window states / styles. * Ripped some of styles.c out to accommodate that. * Messed around in add_window.c to support windows both pre/post mapping for checking window states, etc. And even then that's just basic groundwork. I don't know though -- maybe it's worth working on, but I would be hard pushed (personally) to spec this out before Friday. I would rather see work done on: Style (name=foo,resource=bar,Class=MyClass) InitMapCommand Raise For instance. >>> - 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.) Yes. I would skip this. It's the sort of thing that is best done in one's spare time, and wouldn't hold anyone's interest over the summer. >>> * 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 Well, it's sufficiently interesting that I could probably spec this out before Friday -- but I wouldn't want to do this on my own, I would need the consensus of the other people on this list first of all. > 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. The latter please. I had always thought of allowing the module to define this. > Needless to say this one need lots of discussion, and design descitions, and > probable is hard to mentor. Yes it will be -- I wish there'd have been more time, but I don't think this is a go-er for Friday. Sorry. > 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. Well, yes. The original idea behind this was to just using FIFOs for Sockets (and in doing so, deprecate FvwmConsole -- since it should just then use whichever process communicates with FVWM -- as in: "urxvt -e talktofvwmcommand". That in itself is boring and relatively trivial; adding in ICE support though on top of that though might make it sufficiently more interesting. But now I would argue we need a snortlist of candidates based on what this discussion yields. Again though, time is running out. -- Thomas Adam
