Re: default behavior of window-to-workspace

[Teika Kazura <teika lavabit com>]

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)