> I wouldn't attach a group within a group.. it's asking for a bleeding
Maybe it's not clear from my poor ascii art but groupws2 is attached to
frame1, not groupcw1. I wasn't at home when I sent that email and maybe
I didn't realize that the mua wasn't configured with monospaced fonts. I
just followed this faq entry
http://modeemi.fi/~tuomov/ion/faq/entries/Nested_workspaces.html to get
the layout. Here is the graph again:
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.
> When there's no target winprop, Ion starts searching for a place to
> manage window at, starting from the root window. The target winprop
> has the semantic of changing that start node (plus a few other things).
> WGroupCW shouldn't forward prepare_manage calls, though...
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". Is it
that groupcw1 "refuses" to manage app1 so it forwards the management to
the next group (groupws2) ?
> There could also be some problem with the app2 winprop matching both
> windows. (Some apps are slow at setting the properties.)
I don't think this is the case because if I layout the workspace as a
vsplit with frames A and B -just to say- and app1.target = A and
app2.target = B, then both apps are positioned at the expected places
after startup.
Regards
-Carlos
