Re: [STUMP] window/frame model

[Eric Abrahamsen]

On Sat, Sep 15 2012, Shawn Betts wrote:

> 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.

Thanks! That helps quite a bit. I'm guessing that the line in the first
paragraph should read "looking for a window that is not *any* frame's
top window", right?

>> 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.

Sorry, I'd confused myself between the list of commands bound to keys,
and the list of all available commands. I thinking figuring out which of
these commands moves windows between frames and which just change
display order will probably clear up any remaining confusion.

>> 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

Interesting… That's good to know, though my problem here is with
targeting the correct frame and window, not with sending the keypress.
I'll muddle with it a bit more.

Thanks for your help,
Eric