[Feature Request] Spatial Mode

[phillbush]

[Feature Request] Spatial Mode

[phillbush]

Hi.

I have never used spatial file management before, so I may be wrong; but based on what I have read about it, I think that a spatial file manager needs to provide the following:

1. Open each directory on a proper window.
2. If there's already a window for that directory, focus that window instead of opening a new one.
3. Each directory's window saves its position. So if I open a directory (and there's no already open window for it), its new window should be opened at the same position it was when I opened it before.

First item is the simpler one to implement. Just spawn a new XFiles instance when opening a directory.

Second item requires either XFiles to depend on the hints set by the window manager (so it can know which windows are already open and which window is associated with which directory). Or each XFiles instance would have to be a client that communicates with a XFiles server application that coordinates its instances so that each one can have one window. That is too much and beyound XFiles scope.

Third item requires XFiles to save its position on a single configuration file (where it would keep the placement of the window of each directory); or keep a configuration file within each directory (just like the desktop.ini files in Windows' File Explorer, or the .DS_Store in macos' Finder). That is also beyond XFiles scope.

What is feasible within XFiles scope, though, is to use a "launcher script" that forces XFiles into spatial navigation:

1. XFiles should be changed to call the $OPENER program when opening a directory ($OPENER is already executed when opening a file; opening a directory however is managed by XFiles itself). Opening directories through $OPENER is necessary so that the spatial navigation script can be called to open the directory on a new window. This requires few changes on XFiles side, and fulfills item 1.
2. When this script is run on a directory, it checks the list of windows set by the window manager (using wmctl or whatever IPC facility your window manager provides) for an already open window displaying that directory. If one is found, focus it. If not, spawns a new XFiles instance. This requires no modification on XFiles code, and fulfills item 2.
3. XFiles should somehow provide its caller information about its window before closing its window. This can be easily done by printing the window size and current directory into standard output (or a special file descriptor?) when the window is closed, so the caller script can save that information somewhere. This requires few changes on XFiles side, and fulfills item 3.

Spatial navigation is not a thing I want to implement in XFiles.
But if such behavior can be reproduced by a script and requires only implementing a simple and naive IPC interface on top of XFiles (and if those changes can also leverage unexpected use cases beyond spatial navigation¹) then it is within XFiles scope and I can implement that.

By having such interface of XFiles reporting its caller its window attributes, the user can think of a use different from spatial navigation that we have not imagined when implementing that interface. If I implemented spatial navigation entirely in XFiles itself (rather than implementing a generic interface supporting it) the user could not invent new uses for XFiles.

Conclusion:
Spatial navigation will not be implemented in XFiles. But we can use this issue to discuss how a simple protocol can be implemented on top of XFiles (such as by invoking $OPENER when opening directories, and reporting to the caller the window attributes) for spatial navigation to be implemented using scripts.