> > The second possibility is to implement a custom clientwin_do_manage_alt > > hook and do all the work myself, at least for the windows that must > > reside at nested workspaces. > > This sounds better. > > Although maybe the 'target' winprop should simply behave differently > by default.. it would be a small change.
I think a very flexible approach would be allowing cw groups to be targets. This way arbitrarily complex layouts, including mplex indexes and nested workspaces, could be setup, saved and restored, without depending on a default positioning strategy. In fact that kind of layouts are nowadays setup and saved, but never completely restored because of the initial discarding of previous cw groups. Also the ambiguity issue that motivated my question would disappear as target cw and ws groups of interest are presumably leaf regions in the saved layout (while frames aren't when there are nested ws around). I suppose the problem is that cw groups are volatile regions that in the general case aren't expected to persist from session to session. Maybe some of them could be flagged sticky or something, so they are not discarded at startup. Anyway I've managed myself to get a quick hack working that allows for specifying mx indexes, nested floating and tiled workspaces, unsets initial activity alerts, plus a couple of other goodies that I'm not able to remember now, all that from a clientwin_do_manage_alt hook. It's indecent code that I'd rather keep for myself :), but it talks about the extreme flexibility of ion. Regards -Carlos > > -- > Tuomo >
