[STUMP] won't be around

Hi folks,

I won'd be around for 3 months, not that that will affect development
much :). If you're waiting to hear back from me, keep waiting. I'll be
checking my email periodically.

Keep hacking!

Shawn

[STUMP] NETWM hacking

In the interest of distributed development of Stumpwm, I have set up
a GNU Arch archive.  (See http://wiki.gnuarch.org to learn about GNU
Arch)

The archive is at http://w1.312.comhem.se/~u31227643/archives/ .
There are two branches, stumpwm--cvs--0 and stumpwm--netwm--0.  The
cvs branch is simply what's in CVS, and the netwm branch is my effort
to make Stumpwm NETWM-compliant.  (That seems to have many names, but
the spec is at http://www.freedesktop.org/Standards/wm-spec )

[ Put another way, get "tla" and run:
tla register-archive http://w1.312.comhem.se/~u31227643/archives/
tla get mange <at> freemail.hu--2004/stumpwm--netwm--0 stumpwm
]

So, what's in NETWM?  A lot of things, but these are my particular
goals:

* Recognize window types.  Stumpwm already knows the difference
  between normal and transient windows, but there are also
  docks/panels, ripped-off menus, palettes and such.  Hopefully this
  will eventually make the GIMP less painful to use under Stumpwm.
* Virtual desktops.  If Stumpwm follows the standard, you can use any
  compliant desktop pager you want (including 3ddesktop).

What I've done so far makes no practical difference, but it will be
coming, I hope.

Magnus

[STUMP] starting up

Hello,

I just started playing with stumpwm, and would really appreciate if those
who have spent some time setting it up would share their recipees.

Right now I have stumpwm started from .xsession via detachtty - but how
do I connect to it from slime and make changes?

If I try to start a program with Ctrl-t :, I get the following error
message:

Error in KERNEL::UNBOUND-SYSTEM-ERROR-HANDLER: the variable
/USR/BIN/ATERM is unbound

How do I make sure that after Ctrl-Alt-Bksp stumpwm cleans up after itself?

And what is the meaning of "frame"?  I can't seem to get this right:
Ctrl-t S to split, Ctrl-t f 1 to select an "alternative frame" - and
then...

Thanks a lot!
--ET.

Re: [STUMP] starting up

gene <at> tyurin.com (Eugene N. Tyurin) writes:

> Hello,
>
> I just started playing with stumpwm, and would really appreciate if those
> who have spent some time setting it up would share their recipees.
>
> Right now I have stumpwm started from .xsession via detachtty - but how
> do I connect to it from slime and make changes?
>

My .xsession looks like this :

      lisp -init $HOME/.stumpwm

I start CMUCL with a specific init file that adds personnal command and
then loads stumpwm. Then I connect with slime when needed.

> If I try to start a program with Ctrl-t :, I get the following error
> message:
>
> Error in KERNEL::UNBOUND-SYSTEM-ERROR-HANDLER: the variable
> /USR/BIN/ATERM is unbound
>

By default 'Ctrl-t :' is bound to 'eval-line which try to eval a lisp
sexp plus there is no reference to /usr/bin/aterm in the stumpwm
code. Have you modified a stumpwm variable that talk about 'aterm'? Can
you provide backtrace on this error?

Re: [STUMP] starting up

> By default 'Ctrl-t :' is bound to 'eval-line which try to eval a lisp
> sexp plus there is no reference to /usr/bin/aterm in the stumpwm
> code. Have you modified a stumpwm variable that talk about 'aterm'?
> Can you provide backtrace on this error?

I apologize - that was just a brain-fart.  I kept thinking of C-t ! and
doing C-t :.  My bad...

How do you connect with SLIME to a socket that detachtty opens?
slime-connect wants a TCP port...

--ET.

Re: [STUMP] starting up

gene <at> tyurin.com (Eugene N. Tyurin) writes:

>> By default 'Ctrl-t :' is bound to 'eval-line which try to eval a lisp
>> sexp plus there is no reference to /usr/bin/aterm in the stumpwm
>> code. Have you modified a stumpwm variable that talk about 'aterm'?
>> Can you provide backtrace on this error?
>
> I apologize - that was just a brain-fart.  I kept thinking of C-t ! and
> doing C-t :.  My bad...
>

Ok, so the variable /usr/bin/aterm is unbound, you should have quoted it


> How do you connect with SLIME to a socket that detachtty opens?
> slime-connect wants a TCP port...
>

I don't understand your question (and I don't use detachtty). Here's how
I do: I call "lisp -init $HOME/.stumpwm" in my .xsession. Then my
.stumpwm file contains the following:

--8<-------------------------------
;; Swank server (just a "M-x slime-connect" in Emacs then)
(require 'swank)
;; More responsive than (swank:create-swank-server 4005 :spawn) but
;; don't accept multiple connection
(mp:make-process #'(lambda () (loop (swank:create-swank-server 4005))))

;; Stumpwm

[STUMP] tree-height and tree-width

Look closely at these function definitions in core.lisp:

(defun tree-x (screen tree)
  (tree-accum-fn tree #'min (lambda (n)
			      (let ((f (frame-data screen n)))
				(frame-x f)))))

(defun tree-y (screen tree)
  (tree-accum-fn tree #'min (lambda (n)
			      (let ((f (frame-data screen n)))
				(frame-y f)))))

(defun tree-width (screen tree)
  (tree-accum-fn tree #'+ (lambda (n)
			    (let ((f (frame-data screen n)))
			      (frame-width f)))))

(defun tree-height (screen tree)
  (tree-accum-fn tree #'+ (lambda (n)
			    (let ((f (frame-data screen n)))
			      (frame-height f)))))

tree-x and tree-y are correct.  tree-width and tree-height are not.
For example, if you have two frames next to eachother, tree-height
will add their heights and return twice the correct result.

One way to fix this is to add tree-right and tree-bottom, making them
similar to tree-x and tree-y, and define tree-width as (- tree-right
tree-x) and likewise for tree-height.  But this would mean traversing
the tree twice to get width or height.  Can someone see a more elegant

Re: [STUMP] tree-height and tree-width

> Look closely at these function definitions in core.lisp:
>
> (defun tree-x (screen tree)
>   (tree-accum-fn tree #'min (lambda (n)
> 			      (let ((f (frame-data screen n)))
> 				(frame-x f)))))
>
> (defun tree-y (screen tree)
>   (tree-accum-fn tree #'min (lambda (n)
> 			      (let ((f (frame-data screen n)))
> 				(frame-y f)))))
>
> (defun tree-width (screen tree)
>   (tree-accum-fn tree #'+ (lambda (n)
> 			    (let ((f (frame-data screen n)))
> 			      (frame-width f)))))
>
> (defun tree-height (screen tree)
>   (tree-accum-fn tree #'+ (lambda (n)
> 			    (let ((f (frame-data screen n)))
> 			      (frame-height f)))))
>
> tree-x and tree-y are correct.  tree-width and tree-height are not.
> For example, if you have two frames next to eachother, tree-height
> will add their heights and return twice the correct result.
>
> One way to fix this is to add tree-right and tree-bottom, making them
> similar to tree-x and tree-y, and define tree-width as (- tree-right
> tree-x) and likewise for tree-height.  But this would mean traversing
> the tree twice to get width or height.  Can someone see a more elegant

Re: [STUMP] tree-height and tree-width

Shawn Betts <sabetts <at> vcn.bc.ca> writes:

> Given that the number of frames are probably never going to be more than
> 9, walking the tree twice is probably fine. Also, having tree-bottom and
> tree-right would be useful anyway. I see no problem with your proposal.

Like this:

Unfortunately this doesn't fix the problem I thought it would solve.
If you have frames like this:

+-------+-------+
|       |   1   |
|       |       |
|   0   +-------+
|       |   2   |
|       |       |
+-------+-------+

and remove first 1, then 2, frame 0 will cover twice the height of the
screen.  My patch doesn't change that a bit.  I'll keep investigating.

While I'm here, a patch to make C-t C-n not abort in an empty frame:

Re: [STUMP] tree-height and tree-width

Magnus Henoch <mange <at> freemail.hu> writes:

> Unfortunately this doesn't fix the problem I thought it would solve.
> If you have frames like this:
>
> +-------+-------+
> |       |   1   |
> |       |       |
> |   0   +-------+
> |       |   2   |
> |       |       |
> +-------+-------+
>
> and remove first 1, then 2, frame 0 will cover twice the height of the
> screen.  My patch doesn't change that a bit.  I'll keep investigating.

Found it.  In split-frame-v, the Y value of the lower frame is set to
the X value plus the height of the upper frame, instead of the Y value
plus the height.

Magnus