On 2008-09-09, Carlos Pita <[EMAIL PROTECTED]> wrote: > groupws1 --- frame1 --- groupcw1 --- window1 > |__ groupws2 --- frame2 --- groupcw2 --- window2 > >> nose, although in theory the code can handle that. Why not just attach >> frame2 directly under groupcw1? > > And then attaching the nested workspace groupws2 directly under frame2? > I'll try that.
You should probably disregard that advice given the improved ASCII schematic, which describes a different kind of setup. > Let me be more precise. The resulting parent is frame2 in both cases, > and the resulting manager is the tilling for frame2 in both cases. It's > exactly as if both winprop targets were pointing to frame2. I don't > understand what do you mean with "forward prepare_manage calls". To manage a window, Ion calls the region_prepare_manage dynamic function on the root window that the window was mapped on. The implementation (mplex_prepare_manage) forwards the request to the currently chosen object managed by it, if it supports region_prepare_manage. If the currently selected object is a WGroupWS, it supports the request, so the implementation groupws_prepare_manage is called, etc. When you set the target winprop, the only difference is that the "root" of the chain of prepare_manage cals is not the root window, but the set target object. In your case, the implementation frame_prepare_manage is called on frame1, which is a wrapper for mplex_prepare_manage, that forwards the request to the implmentation group_prepare_manage on groupws2, if that is the current selected region, etc. Now, there is a parameter to region_prepare_manage that asks it to not forward the request, but there's no winprop to set it. -- Tuomo
