On Sat, 16 Oct 2010 12:13:48 +0200, Christopher Roy Bratusek wrote: > I'm just wondering about the default behavior of > send/copy-window-to-next/previous-workspace: > > I wonder whether switching workspaces by default is desired. I mean when I > move a window > to another workspace it's 50% whether I want to go with, but when I copy it, > I never want > to go with it.
Hmm, make the name "move" obsolete, and create "carry" and "push" may be what you want. Got no good idea for "copy". Copy-stay and copy-go? (Darn.) In this case, it might be better to seperate WS menu from the win-op-menu, so that user can choose. # In fact, I've been wanting a command "carry" which does: # $ mv file1 2 3 dir/ # $ cd dir/ # but I haven't written this simple code for years. # This is "itchy". In firefox, when I open a link in a new tab, # 70% is I want to go see the new tab, but there's no control for # each time. Only "always go to the new tab" option is offered. > Another thing that just came in my mind: in window-ops > toggle there's > "Sticky". This > sticky command is combined sticky and sticky-viewport, wouldn't it be better > to have > separated entries for both? Logically it's perfectly correct. Dunno the practice. (I don't use WS. Some windows are matched to be VP-sticky. When I want to carry a window to another VP slot, I make it temporarily toggle VP stickiness with a key binding, go there, and release it.) In fact, sawfish's "stickiness" is too ambiguous. It sometimes means WS-sticky, otherwise WS-VP-sticky. Should I clean this up? Regards, Teika (Teika kazura)
