Re: default behavior of window-to-workspace

[Christopher Roy Bratusek <zanghar freenet de>]

Am Sat, 23 Oct 2010 15:05:26 +0900 (JST)
schrieb 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.

Well -move is fully okay, if we don't follow the window, what about
{move,copy}-window-to-{next,previous}-workspace{,-follow}?

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

I assume you use GNU Bash:

Variant #1:

mvcd () {

  destination="{!#}"

  mv "${ }"
  builtin cd "${destination}"

}

Variant #2 (not fully compatible, but more 1337):

mvcd () {

	if [[ $1 == --help || $1 == -h ]]; then
		mv --help
		exit 0
	elif [[ ${#} -lt "2" && ${1} != *{*,* ]]; then
		echo "not enough arguments"
		exit 1
	fi

	destination="${!#}"

	if [[ "${destination}" == */ && ! -e "${destination}" ]]; then
		 mkdir -p "${!#}"
	elif [[ -f "${destination}" ]]; then
		echo "destination already exists, but is a file."
		exit 1
	fi

	args=( "$@" )
	unset args[$#-1]
	set -- "${args[ ]}"

	for path in "${args[ ]}"; do
	      test "${path:0:1}" == - && MV_OPTS+="$path " && continue
	      if test "${path}" == "*{,*" ; then
		   mv $MV_OPTS "${path}"
	      else mv $MV_OPTS "${path}" "${destination}"
	      fi
	done

	if [[ -d "${destination}" ]]; then
		builtin cd "${destination}"
	fi

}

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

If you install Taberwocky or TabMixPlus, then you get Context-Menu entries "Open In New
Tab in Background" and "Open In New Tab in Foreground" or whatever the englisch labels are

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

I think we should do that.

Regards,
Chris

> Regards,
> Teika (Teika kazura)