Alopex: a tiling tagging tabbed window manager with fur

bgc1954 · 2012-10-12 19:29:32

Already using the default. I just used the src from my PKGBUILD and edited the ttwm.c--left the config.h as is. Make and then copied the exec to /usr/bin.

Last edited by bgc1954 (2012-10-12 19:33:12)

Trilby · 2012-10-12 19:33:56

Odd. I just installed a complete-vanilla version from the AUR using the default config - no problem here. You haven't tried changing the tv.tv_sec value have you? If that was removed this would be the expected result.

As another test, can you try commenting the 3 lines other than the int declaration that include "sfd". These would be lines 606, 614, and 618.

bgc1954 · 2012-10-12 19:43:52

I just tried removing rectabar from line 618 and rebuilt--it complained about an unused reference to rectabar but it built--and it still ran 100% cpu as shown in htop. I'll try your next suggestion now.

bgc1954 · 2012-10-12 19:57:35

I just commented out line 606, 614 and 618 did make and make install. Now ttwm is running around 1% cpu usage with htop. Looks like you figured it out but I still don't know what it means--not that that makes any difference.

Edit: And no I didn't touch the tv...whatever, if I knew what that was.

Last edited by bgc1954 (2012-10-12 19:59:34)

Trilby · 2012-10-12 20:02:55

Well I know WHAT is happening, but I don't know WHY.

There must be data being sent to ttwm's stdin stream on your system. The change made by commenting those three lines only causes ttwm to ignore the stdin stream. Normally every time a line is received on stdin ttwm would update the rectabar region of the status bar. I have input going into ttwm at a rate of one line every 0.2 seconds, and the processor use doesn't even register in htop (eg 0%).

Is ttwm launched from xinitrc? If so can you post that file, if not, how is it started?

EDIT: I was able to replicate this condition by intentionally piping inappropriate input into ttwm in xinitrc. This makes me pretty sure this is the problem.

Last edited by Trilby (2012-10-12 20:14:19)

bgc1954 · 2012-10-12 20:23:54

Here goes:

#!/bin/sh

#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
#
eval `cat ~/.fehbg`

numlockx &

# Ctrl+alt+backspace kill X
setxkbmap -option terminate:ctrl_alt_bksp &

xsetroot -cursor_name left_ptr &

#exec startfluxbox
#exec openbox-session
#exec pekwm
#exec enlightenment_start
#exec startlxde
#exec ~/bin/monsterwm_run # start monsterwm with conky statusbar
#exec i3 --force-xinerama -V >>~/.i3/i3log 2>&1

# Dwm with conky in status bar
#conky | while read -r; do xsetroot -name "$REPLY"; done &
#exec dwm

# ttwm with conky
#exec dzconky-ttwm &
#conky -c .conkyrc-weather &
exec ttwm

# Conky, conky weather script, and trayer with goomwwm
#conky -c .conkyrc-weather &
#conky -c .conkyrc-oneline &
#trayer --edge bottom --align right --distance 1 --widthtype request --heighttype request --SetDockType true --expand true --transparent true --alpha 255 &
#exec goomwwm

I haven't changed a thing in this file for some time and ttwm always worked fine before.

And in case it makes a difference I use xdm login manager so I have a .xsession file

#!/bin/sh

#
# ~/.xsession
#
# Executed by xdm/gdm/kdm at login
#

/bin/bash --login -i ~/.xinitrc

Last edited by bgc1954 (2012-10-12 20:26:45)

Trilby · 2012-10-12 20:39:10

Ah, that's the problem.

I don't use a login manager, but I just implemented a similar command as what you login manager does, "/bin/bash --login -i ~/.xinitrc" upon starting X, and I again replicated the problem.

It seems that command does not provide a normal tty-like stdin stream to xinitrc, and thus the stdin that is passed on to ttwm does not work.

Last edited by Trilby (2012-10-12 20:40:21)

bgc1954 · 2012-10-12 20:44:10

Hmmm...I kinda figured it wasn't the .xinitrc per se as I tried one with nothing in it but exec ttwm and cpu usage was still thru the roof. So maybe my solution is to just make a symlink. I'll try that out, now that I just thought about it.

Edit: Nope, that doesn't help. Same problem. For me, a login manager isn't strictly needed but my wife also uses this desktop and she knows just enough about computers to check her email so I don't want to confuse her without xdm.

It feels like I'm becoming a bit of a PITA...first firefox and now xdm.

Last edited by bgc1954 (2012-10-12 20:57:02)

Trilby · 2012-10-12 20:57:55

I'm reading up on this. It seems that xdm (and potentially other login managers) do not provide a stdin stream to their child processes. This seems very bad to me, but if it is reality I'll have to recommend a way to deal with it.

EDIT: ~~solution:~~ (edit: failed solution)

<redacted>

This creates a stdin stream from /dev/null.

Last edited by Trilby (2012-10-30 12:02:33)

bgc1954 · 2012-10-12 21:51:29

Trilby wrote:

I'm reading up on this. It seems that xdm (and potentially other login managers) do not provide a stdin stream to their child processes. This seems very bad to me, but if it is reality I'll have to recommend a way to deal with it.
EDIT: solution:
exec 1</dev/null
exec ttwm
This creates a stdin stream from /dev/null.

This doesn't seem to work for me and I'm on my netbook now still using xdm.

Trilby · 2012-10-12 22:22:20

Sorry, there was a typo there - that should be "exec 0</dev/null" to redirect stdin.

bgc1954 · 2012-10-12 23:03:45

Unless I'm missing something, "exec 0</dev/null" still doesn't stop the high cpu usage. Just for giggles, I also tried installing slim and gdm and they all display the same problem.

Edit: Just checking on my desktop and now I'm seeing something that I didn't notice before. Now, ttwm is using about 64% cpu and /usr/bin/X :0 auth /var/lib/xdm/authdir/authfiles...etc is using the other 30+% with the "exec 0</dev/null" line in my .xinitrc.

Last edited by bgc1954 (2012-10-12 23:47:53)

Trilby · 2012-10-13 00:02:01

I'll try installing XDM so I can try to replicate this under the same conditions.

Edit: this is really ugly, but it works, in xinitrc:

while sleep 1; do echo; done | exec ttwm

There has to be some way to get display managers to connect a stdin stream ... but I can't find it.

Last edited by Trilby (2012-10-13 01:04:05)

bgc1954 · 2012-10-13 02:49:21

I can confirm that your hack works on this end as well, but it has the side effect that dzen/conky won't display and I can't even get my script that I used in rectabar to display anything in the statusbar now. I wish I could be more help.

Trilby · 2012-10-13 03:10:52

I don't see how this could possibly affect dzen. And any rectabar script can just be pipped into ttwm - then there'd be no need for this while loop hack.

bgc1954 · 2012-10-13 03:34:13

Sorry, I don't know how or why but somehow my ~/bin directory isn't being read anymore and I had to put the whole path into my .xinitrc and now dzen/conky works. As I'm writing this I'm thinking that changing .xsession to a link instead of the other file I had before changed my paths somehow. I'll check this out later but for now everything seems to be back to normal. Thx Trilby.

Edit: That's really strange. For some reason the "export PATH=...etc" in my .bashrc isn't working anymore and all my scripts in ~/bin don't even show up in dmenu anymore. I'm tired of looking at this d*** screen anymore so maybe tomorrow will bring a fresh start.

Edit: I guess all the install, uninstall of display managers and trying without them did something to the way I was being logged in--also my changing my .xsession file to a symlink likely was to blame. I also found my .dmenu_cache is now located in ~/.cache/dmenu_run so when I finally staightened out my PATH problems, I had to delete the file so that dmenu would generate a new one with the proper PATH. Just another day it seems.

Last edited by bgc1954 (2012-10-14 17:25:47)

bgc1954 · 2012-10-14 19:09:40

Hi, me again. I know I must be doing something wrong, but I cobbled together a script from various sources which displays fine in ttwm and doesn't consume alot of resources. My problem is that everything seems fine until I try to exit with mod+shift+q. Ttwm doesn't exit and then the ttwm keyboard commands don't work anymore and I have to kill it with ctrl+alt+backspace. My .xiniitrc

#!/bin/sh

#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
#
eval `cat ~/.fehbg`

numlockx &

# Ctrl+alt+backspace kill X
setxkbmap -option terminate:ctrl_alt_bksp &

xsetroot -cursor_name left_ptr &

# ttwm with conky
#exec /home/brian/bin/dzconky-ttwm &
while true; do status.sh; done | exec ttwm
#while sleep 1; do echo; done | exec ttwm

My status.sh script:

#! /bin/sh

while true; do

eval $(awk '/^cpu /{print "previdle=" $5 "; prevtotal=" $2+$3+$4+$5 }' /proc/stat); sleep 0.4; eval $(awk '/^cpu /{print "idle=" $5 "; total=" $2+$3+$4+$5 }' /proc/stat); intervaltotal=$((total-${prevtotal:-0})); echo "{#cccccc}CPU:$((100*( (intervaltotal) - ($idle-${previdle:-0}) ) / (intervaltotal) ))%:$(cat /proc/cpuinfo | grep MHz | awk '{printf "%.0f\n", $4}')Mhz RAM:$(free -m | grep -i /cache | awk '{print$3}')Mb T:$(($(cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp1_input) / 1000))C"

sleep 5

done

Obviously, I'm not proficient in bash so I hope I'm not doing something too stupid. I'm sure something more elegant is possible but the script does duplicate what I can display with dzen/conky and dzen/conky doesn't have any problems exiting ttwm or keyboard freezing. I'm quite happy using dzen/conky but I too like to tinker and learn.

Trilby · 2012-10-14 20:40:33

This is actually something I've been trying to figure out too. In various tests I have seen the behavior you describe, and I know the source, I just don't yet know all the details.

X runs until xinitrc completes/exits. If I have "exec cab | ttwm" where cab is a program that sends status info through the pipe to ttwm, then everything works as expected. When I tried "exec tail -f /dev/null | ttwm" as a potential solution for the lack of stdin from previous posts, I saw the behavior you describe. TTWM can exit with Mod+Shift+Q, but "tail" would still be running and would keep the X session alive until "tail" was killed.

From what I've deduced, some programs/commands will exit when their stdout pipe is broken, others will not. Specifically cab will exit when it's output pipe is broken, tail will not.

I suspect your status.sh script will exit when it's stdout pipe is broken, however the while loop in your xinitrc will keep restarting. So, long story short, since you have the while loop in the script, remove it from xinitrc. In other words

exec status.sh | ttwm

Edit: I just tested this with a similar script, and it works as expected with the above exec line.

FYI: if I understand the intent of the script correctly, you'll probably want to remove the newline ('\n') from the printf in the middle. A newline character is what triggers a refresh of rectabar so if you send two lines at once separated by a newline, the first line will never actually get displayed. Or more accurately, it may get displayed, but only for the few milliseconds it takes to read and display the next line.

Last edited by Trilby (2012-10-14 20:52:03)

bgc1954 · 2012-10-14 22:03:31

Thx again. So I guess I didn't screw it up too badly.

I changed my .xinitrc to reflect your suggestion and it works as you said it would. I kind of thought I was using too many while loops. I also removed the \n in my script but that doesn't seem to do anything as my status bar display appears the same--I guess if it's not necessary, why have it there. Now, I can exit with mod+shift+q but I have to hit that key combo two or three times for it to work.

Edit: Now maybe I can ditch dzen/conky. Actually, I sometimes have to hit mod+shift+q many more than 2 or 3 times.

Last edited by bgc1954 (2012-10-14 22:08:08)

Trilby · 2012-10-14 22:29:49

Ah, yes, you shouldn't have to hit Mod+Shift+Q more than once, you just have to hit it and wait up to 5 seconds for your script to end.

X will keep running as long as your status script is running. The script gets closed from the broken stdout pipe (broken because the receiver ttwm exited), but it will not encounter this broken pipe until it tries to write to it. In your script, it only writes every 5 seconds, so their could be up to a 5 second delay between when ttwm exits, and when X ends.

I am working on better solutions, but so far every option seems to have nasty side effects for at least some use cases. Using a fifo seems best, but ttwm can't create the fifo while also allowing something in xinitrc to start writing to it.

I'd consider recommending three lines in xinitrc to 1) create a fifo, 2) start a process (eg status.sh) to write to the fifo, then 3) start ttwm. But aside from the inelegance of needing three commands, this will cause real problems for anyone who doesn't want to use the fifo (this is an odd side effect of using "select()" to read from a one-sided fifo).

I've also considered having the input-generating command (eg status.sh) passed as a parameter to ttwm and ttwm would execute the provided command and create an input pipe. But I have yet to find a good way to kill a process started in this way, and ttwm then hangs indefintely on exit.

Some websites suggest a fork/exec to get around this problem, but this requires a bit of code I'd prefer to avoid.

Needless to say, I'm still brainstorming - and defintely open to input of any good proposals.

bgc1954 · 2012-10-14 22:44:04

That makes sense. I can wait a few seconds now that I understand what's going on. I shortened the sleep to 2 in my script and that makes the exit delay seem almost none existant. Beats the heck out of pounding my keyboard to death. Thanks for the explanation.

Edit: I think I'll wait for a while to try and learn about fifo's, Just getting this script to do what I wanted caused enough brain strain for today.

Last edited by bgc1954 (2012-10-14 22:47:49)

Trilby · 2012-10-14 22:53:14

I ditched the fifo idea and I got a "popen()" solution working.*

I just pushed the update on git. It is "backwards compatible" and will still accept input on stdin if ttwm is not passed any arguments. But it is better to pass the input generating program/script as the first parameter of ttwm. For example, the following works:

exec ttwm /path/to/status.sh

This has two benefits: first, it gets rid of any delay in quitting, when you tell ttwm to quit, it quits; second, it allows an "exec" command in launching the window manager to work properly and replace the xinitrc script (see the difference of a pstree ran from starting x with "exec ~/status.sh | ttwm" vs "exec ttwm ~/status.sh")

Note that ttwm only currently uses the first argument provided. If a input-generating command needs its own parameters you'll probably need to quote them as in the following:

exec ttwm "/path/to/status.sh arg1 arg2"

---------------

*Note so others might learn from my mistakes: when a process is opened with "popen()" I had wanted to close it with "pclose()" before ttwm exited. plcose, however will apparently block until the process completes, so without a way to kill the child process, ttwm would hang. It turns out there is no need whatsoever to call pclose. Ttwm will exit normally, and the child process will also be terminated.

Last edited by Trilby (2012-10-14 23:02:10)

bgc1954 · 2012-10-15 03:39:54

Genius! Sorry...I say that probably too much. This works excedingly well. I have great respect for programmers of your level. I tinker but cannot match your actual knowledge since I haven't put in the hours to learn all that you have. I am a wm surfer but ttwm is one of my favorites and I hope that I can continue to appreciate your work. Thanks for your input and respecting my limited knowledge.

Trilby · 2012-10-15 03:47:39

Thanks bgc. I consider myself just a tinkerer too - but it's a hobby I enjoy, so I've picked up some tricks. I've learned much of it since coming to arch, so I'm happy if my contributions can be useful to others here.

JLloyd13 · 2012-10-15 22:51:16

will definitly be trying this

Arch Linux

#126 2012-10-12 19:29:32

Re: Alopex: a tiling tagging tabbed window manager with fur

#127 2012-10-12 19:33:56

Re: Alopex: a tiling tagging tabbed window manager with fur

#128 2012-10-12 19:43:52

Re: Alopex: a tiling tagging tabbed window manager with fur

#129 2012-10-12 19:57:35

Re: Alopex: a tiling tagging tabbed window manager with fur

#130 2012-10-12 20:02:55

Re: Alopex: a tiling tagging tabbed window manager with fur

#131 2012-10-12 20:23:54

Re: Alopex: a tiling tagging tabbed window manager with fur

#132 2012-10-12 20:39:10

Re: Alopex: a tiling tagging tabbed window manager with fur

#133 2012-10-12 20:44:10

Re: Alopex: a tiling tagging tabbed window manager with fur

#134 2012-10-12 20:57:55

Re: Alopex: a tiling tagging tabbed window manager with fur

#135 2012-10-12 21:51:29

Re: Alopex: a tiling tagging tabbed window manager with fur

#136 2012-10-12 22:22:20

Re: Alopex: a tiling tagging tabbed window manager with fur

#137 2012-10-12 23:03:45

Re: Alopex: a tiling tagging tabbed window manager with fur

#138 2012-10-13 00:02:01

Re: Alopex: a tiling tagging tabbed window manager with fur

#139 2012-10-13 02:49:21

Re: Alopex: a tiling tagging tabbed window manager with fur

#140 2012-10-13 03:10:52

Re: Alopex: a tiling tagging tabbed window manager with fur

#141 2012-10-13 03:34:13

Re: Alopex: a tiling tagging tabbed window manager with fur

#142 2012-10-14 19:09:40

Re: Alopex: a tiling tagging tabbed window manager with fur

#143 2012-10-14 20:40:33

Re: Alopex: a tiling tagging tabbed window manager with fur

#144 2012-10-14 22:03:31

Re: Alopex: a tiling tagging tabbed window manager with fur

#145 2012-10-14 22:29:49

Re: Alopex: a tiling tagging tabbed window manager with fur

#146 2012-10-14 22:44:04

Re: Alopex: a tiling tagging tabbed window manager with fur

#147 2012-10-14 22:53:14

Re: Alopex: a tiling tagging tabbed window manager with fur

#148 2012-10-15 03:39:54

Re: Alopex: a tiling tagging tabbed window manager with fur

#149 2012-10-15 03:47:39

Re: Alopex: a tiling tagging tabbed window manager with fur

#150 2012-10-15 22:51:16

Re: Alopex: a tiling tagging tabbed window manager with fur

Board footer