On Mon, Feb 17, 2003 at 11:10:05PM +0100, Per Olofsson wrote: > Tuomo, could you look over the code and tell me if I've done anything > wrong when interfacing with Ion? Thanks :)
Seems ok for the most part. You might want to implement a draw callback to draw a border to be seen with shaped dockapps. You should not eventually need handle_event_hook at all, but clientwin_handle_configure_request is still not doing things properly either so that won't work at the moment. You should implement region_remove_sub (or whatever the dynfun was) and should not need the watch stuff. As WRegion::uldata is also reserved for the parent region to use for whatever data it needs, the dock's dockapp list is not absolutely necessary, BUT although so far the policy has been to use the single WThing sub list, this will change in the next (?) release. A word about the upcoming changes might actually be in place. The ugly WWinGeomParams stuff will be gone and not all regions can be nested anymore. Instead, windowless regions like workspaces will be dedicated "manager" regions that share the same parent region with the regions they manage. It is up for each region that manages others to keep list of the managed regions (instead of the above mentioned WThing sub list that is no longer up to this task). So a WScreen directly contains as subregions all the frames, workspaces and viewports (I didn't yet remove them), but it only manages the viewports, which manage the workspaces and those again the frames. Much of the subregion this and that functions will be changed to managed region this and that. The various create_region functions will also now directly get the parent region and geometry (instead of screen and the ugly WWinGeomParams) as argument because all the attachment/management setup stuff is done separately with the manager region that may be the same or different region, if any. I hope that made any sense. It may seem complicated but is actually much simpler than the current kludge and should more easily allow for sticky (PWM) windows and PWM workspaces that span multiple Xinerama screens. I will most likely also be simplifying the keyboard grabbing code and clientwin_bindings will most likely be gone. Although the innermost window grabbing a key would still get the key press (the outmost gets it from X), grabs could only be held directly by windowed regions (but not WClientWins because of the ICCCM) instead of grabbing everything on the root, which was causing some problems. Windowless regions like a WWorkspace could still have key bindings associated to them by grabbing the keys on all the managed regions. This change should also simplify the code that has gotten a bit too complex and bloated. I guess I've bored everyone more than enough now. PS. Thanks for pointing out the bugs. -- Tuomo
