On Tue, Feb 18, 2003 at 01:07:11AM +0200, Tuomo Valkonen wrote: > 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.
A border around the whole dock? Like the tabs? > 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. I know, I saw the todo comment. > You should implement region_remove_sub (or whatever the dynfun was) and > should not need the watch stuff. Ok. > 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. Which means I should keep the dockapp list, since the dockapps will be children of a WScreen? Even if I can store data in uldata I still need to be able to iterate over the dockapps. > 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. If I understand things correctly, there will be a separate hierarchy for the actual X window parent-child relationships and the "managing" relationships. Which makes sense since only a managing relationship shouldn't impose any restrictions on window geometry (which is now circumvented with WWinGeomParams). But does this mean that there will be separate lists for windowed and windowless (managing) children of a WScreen? Or did I get everything wrong? :) > 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. Not at all, this is interesting. I thing it's good that you share your thoughts behind Ion's design decisions. There isn't any other documentation on Ion's architecture, apart from the source code. /Pelle
