#1 Make closed windows remember their frame

[Arnout Engelen]

For example in Eclipse, switching 'perspectives' may open/close 'detached' windows.

It would be nice if such a window, when re-opened (the window ID is stable), is placed in its original frame again (if possible, and perhaps optionally).

[Igor Mosyagin]

Why bother with that thing if you can add it to cfg_kludges? (window ID is stable, right?)
We should consider adding a 'simple' way to add a hook for any window, maybe

[Arnout Engelen]

If we can document a way to do this with the existing cfg_kludges functionality that would be great - could you elaborate on how it can be used to achieve what I described?

I'm not sure the window ID is stable across restarts of the application, I'd have to check.

[Igor Mosyagin]

Looks like I was wrong.

Steps to achieve that from ionside:
0. Detect window (already did it via XID)
1. Add hook to cfg_kludges
2. Force ion to reread that information (for now, restart only)
3. ENJOY.

There are some troubles here, though:
As one can see in ioncore/ioncore_winprops.lua:83 do_add_winprop,
ion can distinguish only class/role/instance for now (that is logically fine because, afaik, you cannot predict XID a priori). I don't think that it's hard to extend that behaviour to check for xid. Actually, I remember stuff like defwinprop{class="XTerm", instance="xterm",name="mail",target="mailscratchrah} to work, but as I can see it don't work for "xid=".
The second (major one) problem is that afaiu cludges are checked at the creation of the window i.e. even if I do a proper defwinprop in a cludes window for already opened window, I won't be able to see that on restart of ion3, it will only "make sense" at the new windows of that type.
We should discuss possible solutions on IRC.

Regarding your problem - is window ID the only thing that distinguish your windows?

[Arnout Engelen]

The window ID currently appears to be the only way to distinguish the windows.

A bugreport to add more useful titles has been in eclipse's bugtracker since 2007: https://bugs.eclipse.org/bugs/show_bug.cgi?id=187220

Defining a 'target' with winprops is interesting, but I'd like to be able to move windows around - after closing/opening, the window should again be in the spot where it was when it was last closed. A winprops 'target' seems a bit too 'static' imho.

[Arnout Engelen]

With your pointers and a bit of help from deryni on IRC I arrived at the following:

eclipseparentframes = {};

function restoreEclipseWindowLocation(win)
if "Eclipse"==win:get_ident().class then
eclipseparent = eclipseparentframes[win:xid()];
if (not(eclipseparent == nil)) then
if (not(eclipseparent == win:parent())) then
eclipseparent:attach(win);
eclipseparent:switch_nth(eclipseparent:get_index(win));
end
end
end
end
function recordEclipseWindowLocations(win)
if "Eclipse"==win:get_ident().class then
eclipseparentframes[win:xid()] = win:parent();
end
end

ioncore.get_hook('clientwin_mapped_hook'):add(restoreEclipseWindowLocation);
ioncore.get_hook('clientwin_property_change_hook'):add(recordEclipseWindowLocations);

Appears to work great so far!

[Igor Mosyagin]

Looks nice.
I think we have to make some kind repo for user scripts with descriptions
Or just a wiki category.

[Arnout Engelen]

Strange: it seems the 'eclipseparent:attach(win);' causes eclipse and notion to get into some kind of endless loop (each taking about 50% cpu) - this is with the latest notion from git. Will have to look into that...

[Arnout Engelen]

Not sure what went wrong back then - it now works. Might be nice to have a generic lua function that allows you to easily specify which windows should remember their frames like this.