events & actions

Marius Nita marius at cs.pdx.edu
Mon Nov 4 00:47:39 EST 2002


since xor is planning on starting on events next, here are some further ideas
that should be considered.

i was thinking that events and signals should be handled in the same way. colo
expanded this to include actions as well.

so what are actions? i have only vague thoughts about this so far, but an
action is associated with something which happens in the wm at the user level.
for example, shading a window is an action. so is moving one, closing one,
opening a menu, highlighting the next item in a menu, etc. this works much
like epist's actions.

so we'll have an event queue in the wm. in this event queue sit ob events, not
X events. ob events are: X events, Signal events and Action events. (and
maybe others?) when any of these 3 types of events are triggered, they are
placed in the ob event queue, which is processed sequentially. (bubbye,
idiotic races.) 

so we'll have a OBEventHandler base class, (or are we going to have a
OBEventHandler base, and OBSignalEventHandler, OBActionEventHandler and
OBXEventHandler, which derive OBEventHandler?) and we'll have 3 types of
events: OBXEvent, OBSignalEvent and OBActionEvent, all of which derive from
OBEvent.

i think this will rock. OBXEvent will hold the XEvent pointer, OBSignalEvent
will hold the signal to handle, and OBActionEvent will hold a pointer to the
Action object, which holds enough information about what needs to be done. in
the ob event loop, it will be a matter of telling the right object to handle
the event. I'm still not sure about how to exactly identify which handler func
is called.

now, these actions are cool things. why? because it opens the door to an
action-based highly configurable system--we discussed this a while back. the
user will be potentially able to say

 # move window with alt-left click
 action {
 	binding Mod1-LeftClick
	location all
	action startMove
 }

 # resize window with alt-right click
 action {
 	binding RightClick
	location rightGrip
	action startResize
 }

well not quite but you get the idea. none of the ob behavior will be
hardcoded; it will come with a default action file. pwm does this to an
extent, maybe we can learn tons by looking at that.

oh, also, one more reason that actions are cool is because they are one
codepath for everything. the ONLY time ob will resize a client window is when
it executes a startResize action. So somehow, a lot of x events will have to
be dealt with via actions. (And maybe even some signals, like -USR1 will
execute a Reconfigure action or something.)

so one codepath for all wm<->user things, and one codepath for all event
handling. really cool stuff, i think.

anyway,
marius




More information about the openbox mailing list