Re: [STUMP] window/frame model

[Shawn Betts]

On Fri, Sep 14, 2012 at 1:05 AM, Eric Abrahamsen
<address@hidden> wrote:
> I've noticed for a while that I don't really understand Stumpwm's model
> of splitting windows among frames. I've tried to write a few user
> functions that, for instance, send keypresses to a different window
> without shifting focus to that window, and that's made it even clearer
> to me that I'm not really getting it.
>
> My understanding so far:
>
> One frame is easy: all the windows belong to that frame, and they're
> ordered so that `next' and `prev' will cycle through them.
>
> Then you split frames. The original frame keeps the top window and the
> rest of the windows, while the "second" window (that would have been
> found with `next') goes to the new frame. The new frame *only* contains
> this second window, so that `next-in-frame' in the new frame tells you
> "No other window". So far so good.
>
> Further frame-splitting follows the same rule, so that with each split
> you're popping the next "second" window and placing it alone in the new
> frame. Unless the frame you're splitting only has one window to begin
> with, in which case the window for the new frame is taken from a frame
> that still has un-visible windows.
>
> Things get really confusing when I start using the `pull-hidden-*'
> commands.
>
> I understand that I can pull a window from one frame window list into
> another using the `pull 0-9' commands. But how does `pull-hidden-*'
> decide where to get its frames from? Is it a global list of windows in
> the current group? I generally use full-screened frames on two heads,
> but when I need to get a little complicated and split a single head, I
> find myself fighting to get the right windows in the right frames.
> Possibly this is because I use `pull-hidden-other' too much.

pull-hidden-next and pull-hidden-previous sort all the windows in the
group by their number. Then it finds the current window in that list.
Then it walks forward in the list or backward, depending on if its the
next or previous command, looking for a window that is not its frame's
top window. The first one it comes across it pulls into the current
frame.

pull-hidden-other sorts all windows in the group by their last access
time. So windows that were recently focused are at the beginning of
the list. Then it walks that list until it finds a window that is not
its frame's top window. It pulls that window into the current frame.

> Anyway, can anyone enlighten me as to exactly how Stumpwm decides to
> pull windows? Would it be nice to have a command that shows the
> window-list for the current frame?

echo-frame-windows (aliased to frame-windows) will do this.

> In a semi-related question, is anyone doing anything like the following,
> and/or could anyone help me fix this?
>
> --8<---------------cut here---------------start------------->8---
> (defun send-key-other-window (dir)
>   ;; `last' of `group-frames' doesn't actually return the most
>   ;; recently focused frame, just the last in a list apparently
>   ;; starting at top left. How do we sort according to most recently
>   ;; focused?
>   (send-fake-key
>    (frame-window (car (last (group-frames (current-group)))))
>    (kbd dir)))
>
> (defcommand scroll-other-window-down () ()
>             "Scroll other window down."
>             (send-key-other-window "Next"))
> (define-key *root-map* (kbd "d") "scroll-other-window-down")
>
> (defcommand scroll-other-window-up () ()
>             "Scroll other window down."
>             (send-key-other-window "Prior"))
> (define-key *root-map* (kbd "u") "scroll-other-window-up")

A lot of windows, for security reasons, will not accept faked keyboard
events. But some programs can be told to accept them with an
XResource. If you want to make sure that windows are receiving your
fake events, use the program xev. It will show a window and print out
every event it gets to the terminal. You should be able to find your
fake events in the output. If not, something buggy is going on.

-Shawn