On Sat, Sep 15 2012, Shawn Betts wrote: > On Fri, Sep 14, 2012 at 1:05 AM, Eric Abrahamsen > <e...@ericabrahamsen.net> 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 _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
