Alopex: a tiling tagging tabbed window manager with fur

bgc1954 · 2013-02-24 20:24:11

I just installed tamsyn-font to check it out and no problem here, although I had to log out and back in before tamsyn showed in xfontsel. I normally use terminus and that shows in xfontsel as well.

HalosGhost · 2013-02-25 01:06:27

Trilby wrote:

In addition to adding the "local" directory to the font path, have you rehashed the font path database?

I did add them to the font path and rehash the font path database. I was using a different xfontsel for terminus than you were, so I switched over to see if maybe yours would work, but it also failed. The thing that rather baffles me is that it functions fine with the default fixed font.

A full copy of my ~/.ttwm_conf.h can be found here. I imagine, as with my other issues so far, this is still just user error on my part, so I'm sorry to ask for so much help.

All the best,

-HG

Trilby · 2013-02-25 01:39:39

The config looks good. Are you adding the local portion to the font path and rehashing in xinitrc? Do these fonts work in other programs that take X font strings?

bgc1954 · 2013-02-25 16:45:39

@HalosGhost - Just a question out of curiosity, how do you startx? Is it with a display manager that maybe doesn't read your .xinitrc--if that's where you set your fontpath. I've used the xorg.conf method of setting my fontpath for years and I don't seem to have your problems with terminus or tamsyn. Maybe just need a new look at font and fontconfig wikis?

ozar · 2013-02-25 18:06:30

Hello HG

For whatever it might be worth, my font paths get inserted into xorg.conf as well and I've had no issues at all with Tamsyn or Terminus fonts under TTWM, so it definitely sounds like a configuration issue of some kind. I've not tried the .xinitrc file for getting fonts recognized although the .xinitrc file is my method of starting WMs. Do let us know what it turns out to be...

Trilby · 2013-02-25 18:18:21

I've also added my font paths to my xorg.conf on the computer I'm on now - and it works well.

My home computer just has it in xinitrc - I don't take as good care of that system, but that works too. I asked where it was set though as - hopefully obviously - if you set the font path and rehash afterttwm starts, it won't work. Setting it in xorg.conf or an xinitrc that gets run should do it.

HalosGhost · 2013-02-25 18:58:13

Hey folks, thanks for the responses. No, I don't have an xinitrc. I use systemd --user to manage my X session. I have the font path updated and rehashed in a user service file. However, I think I may have figured out what the problem is, I'm going to test something in just a moment, and I'll let you know how it goes.

Thank you again for the suggestions and help.

[Edit]: I got it to run! Alright, that's the good news. The bad news is that now, when running ttwm takes 100 percent usage of one of my CPU threads and does so continuously, to the point of driving my processor up to 100°C. Now, while the font thing was clearly user error, I'm having trouble understanding how I could have caused this. Any thoughts? [/Edit]

[Edit 2]: My processor in this machine is an i7 as well, perhaps this is a CPU-specific issue if you haven't noticed it Trilby? [/Edit 2]

All the best,

-HG

Last edited by HalosGhost (2013-02-26 23:25:45)

netfun81 · 2013-02-26 23:07:30

I'm also getting the 100% cpu usage on core 4 (of 8, i7). Tried the latest V2.0 on github and still happening. Was waiting to see if someone else had the issue.

Last edited by netfun81 (2013-02-26 23:09:36)

Trilby · 2013-02-26 23:31:33

@HG & netfun,

Do you use display managers? Do you pass a status generating parameter to ttwm?

If the answers are Yes and No respectively, I know what the problem is, though I thought it was already fixed.

EDIT: to confirm, if the answers are Yes and No, would you mind trying without a display manager, and/or with a parameter like the following:

ttwm "while :; do date; sleep 1; done"

Last edited by Trilby (2013-02-26 23:32:57)

HalosGhost · 2013-02-26 23:33:48

Trilby, I'm sorry to say, I don't use a DM (though, as I mentioned, I use systemd --user to manage my X session if that matters) and though I've tried to figure out the status parameters, I do not currently pass one. So that would be a qualified "no" and a "no."

[Edit]: Testing as you recommended, the 100 percent CPU thread usage issue is gone (and I have a lovely little clock in my status-bar). Good call! Thank you, as always, for your quick and helpful responses! [/Edit]

All the best,

-HG

Last edited by HalosGhost (2013-02-26 23:40:46)

Trilby · 2013-02-26 23:35:47

I suspect starting X with systemd would have the same effect, in this regard, as using a display manager.

netfun81 · 2013-02-27 00:00:27

Trilby,

adding the date also fixed the issue here. I am using a display manager. Thanks!

Trilby · 2013-02-27 00:10:42

Glad that works as a workaround - but that means the old fix isn't working in 2.0. I'll look into this and get a permanent fix put together.

Hmm, I read back through the thread and see I never really did make a conclusive fix for this bug - just a series of improving work arounds.

I know what I need - I need to check it stdin is connected to a real stream. ~~If anyone has a heads up on how to do this, let me know, otherwise I'll search on this and see what I can find.~~ Found it: fileno(stdin) will return -1 if stdin is not a real stream.

I just used this test to put in a fix. I know the conditional test will work to detect the problem, but I'm not yet sure if what I did will fix it. Please try the new code just pushed to git and let me know.

Last edited by Trilby (2013-02-27 00:29:31)

netfun81 · 2013-02-27 02:55:30

Trilby,

tried the new build without the date and my cpu went back to 100%. The date workaround works great though.

Trilby · 2013-02-27 03:09:56

I just uploaded another attempt if you wouldn't mind testing.

netfun81 · 2013-02-27 04:49:04

sorry, same issue. no hurry to fix since the workaround is fine. Besides now I know the display manager was affecting ttwm i dont mind dumping it.

ozar · 2013-02-27 14:19:16

netfun81 wrote:

Besides now I know the display manager was affecting ttwm i dont mind dumping it.

lol.. every display manager i've ever tried came with too many side effects so i stopped using them altogether about 5 years ago.

hope trilby's update works out for you guys!

Trilby · 2013-02-27 14:31:42

OK, I did fire up xdm again and was able to replicate the problem consistently. This allowed me to actually test potential solutions rather than going with what I thought should work. I've now pushed a solution that works for me with xdm.

Basically the problem is (was) that when ttwm starts, it first checks if it was passed any parameters. If it was, it runs the provided parameter as a subprocess and reads from it. If no command line parameter was passed, it just reads from the standard input. Whenever there is anything to read on the relevant input it updates the status bar. But display managers break (close) the standard streams, and thus there is always an EOF ready to be read and the read loop runs out of control.

The solution was to reopen stdin to point to /dev/tty. A longer term solution is going to be drop the ability to read from stdin and only use command line parameters. I've kept the stdin as an option as it seems to make a more "*nix friendly" program ... programs should be able to use their standard streams. But it seems this ability is not expected for window managers and display managers assume that WMs will in fact not ever try to read from the standard input.

So my internal debate boils down to how much I hold to my "philosophical" view on how good programs should work, versus how pragmatic I am in recognizing that other developers have entirely given up on this good behavior for DMs and WMs.

HalosGhost · 2013-02-27 15:35:38

Trilby, I'm not sure how difficult this would be, but it may provide a solution for you. You could allow a flag in $HOME/.ttwm_conf.h to disable reading from stdin that would be enabled by default (that is, by default, TTWM wouldn't read from stdin) with a comment noting that it will cause a processor race should it be disabled and used with a DM.

Might add some more cruft to the project as a whole though, so it would make sense if you decided to go against it. However, doing so would set a default mechanism that plays nice with other things, and still allows users that know what they're doing and want the "good *nix" functionality to enable it without much difficulty at compile-time.

All the best,

-HG

bgc1954 · 2013-02-27 17:52:00

Wow, I'm late to the party and all the fun going on. Just thought I'd chime in with my own experiences as they are different from HG and netfun. I've been using version 2 since it's release and have not experienced any problems when I start out with xdm display manager. My cpu is a 64 bit AMD but I still run i686 if that might make any difference and I also run a status.sh script with time and date so that's more likely what's making ttwm behave for me.

Quite some time ago this came up in version 1 and it was due to my dm not playing nice with ttwm but I too thought that was rectified. Out of curiosity, I'll have to try running without my status.sh script and see if I encounter the same thing--before I try the new git push.

edit: Sure enough, as soon as I stripped out my status script, ttwm ran cpu to 100%. I tried the new push and now, using xdm, I just get kicked out of ttwm back to xdm if I'm not using my script. With the script, everything runs as it always has. I tried running from tty2 with xinit and it starts up fine without the script and xdm killed.

Last edited by bgc1954 (2013-02-27 18:14:44)

Trilby · 2013-02-27 18:52:49

Well, I sacrified my morals, and ditched the stdin reader. Now any status scripts must be provided as an argument to ttwm rather than pipe to it. This is cleaner than piping input anyways.

If no status script is provided, ttwm uses a "default" of just a simple clock.

netfun81 · 2013-02-27 19:05:58

Trilby,
That last fix did the job. Working fine now. Thanks for quick response! I don't know how others feel but I wouldn't mind command line options. One of my favorite floating wm's is evilwm which allows everything to be configured in one command i.e, evilwm -mask1 Mod4 -mask2 Mod1 -fg black -bg white etc. Hows this? "ttwm -date -cpu -audio -bar top -text grey" etc. Whatever you decide I like it as is too :}

Trilby · 2013-02-27 19:28:41

Some of that may be possible, but some of it definitely isn't.

There are no monitors for cpu, audo, or anything else built into ttwm. I use scroller (scroller.c in the scrollwm repo) to monitor such things and provide the status input.

It would be easy enough to have a status tool that did all that based on command line options though, so the invocation would be something like: ttwm "statustool -date -cpu -audio"

For colors and such other settings, there are many, so parsing a command line for all of them would be rather tedious. I have considered a rc file rather than a config.h for changes, but personally I don't see the justification. Rc files are great for things where the configuration can be expected to change regularly, but they have a cost in data space and start up time that just don't justify their use for something that should not have to change configuration that often.

I know these "costs" are minor - and many other WMs use text (or xml) based configuration files. But as I've said only in a slightly tongue-in-cheek manner before: I have a borderline pathological commitment to resource use minimalism for ttwm, and this is the way it will remain.

I'll gladly add features that have a good value (some costs, but lots of benefits), but rc files, or command line configuration just don't pass that test in my balance sheet.

bgc1954 · 2013-02-27 19:49:29

Trilby wrote:

If no status script is provided, ttwm uses a "default" of just a simple clock.

Like I said, something is still amiss if I don't use my status.sh. Invoking "exec ttwm ~/bin/status.sh" in .xinitrc works perfectly but if I just use "exec ttwm" I get a brief flash of the background and then find myself back at xdm login screen. Since I don't run without my status script, it's all rather moot to me.

HalosGhost · 2013-02-27 20:21:31

Hey Trilby, I have another one of my pesky feature requests for you. With Firefox, the Title in the statusbar displays the whole Tab page-title which becomes very difficult to read (See: Firefox on this page). Is it possible to cut it down so it only displays the program name and nothing more? If this is already possible, would you mind letting me know how to do so?

All the best,

-HG

Last edited by HalosGhost (2013-02-27 20:24:15)

Arch Linux

#301 2013-02-24 20:24:11

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

#302 2013-02-25 01:06:27

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

#303 2013-02-25 01:39:39

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

#304 2013-02-25 16:45:39

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

#305 2013-02-25 18:06:30

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

#306 2013-02-25 18:18:21

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

#307 2013-02-25 18:58:13

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

#308 2013-02-26 23:07:30

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

#309 2013-02-26 23:31:33

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

#310 2013-02-26 23:33:48

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

#311 2013-02-26 23:35:47

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

#312 2013-02-27 00:00:27

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

#313 2013-02-27 00:10:42

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

#314 2013-02-27 02:55:30

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

#315 2013-02-27 03:09:56

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

#316 2013-02-27 04:49:04

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

#317 2013-02-27 14:19:16

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

#318 2013-02-27 14:31:42

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

#319 2013-02-27 15:35:38

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

#320 2013-02-27 17:52:00

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

#321 2013-02-27 18:52:49

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

#322 2013-02-27 19:05:58

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

#323 2013-02-27 19:28:41

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

#324 2013-02-27 19:49:29

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

#325 2013-02-27 20:21:31

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

Board footer