Alopex: a tiling tagging tabbed window manager with fur

bgc1954 · 2013-02-11 20:07:26

@Trilby - I have Diablo 2 installed on my netbook as well--your comment about hardware you're running ttwm on reminded me of that--and there, with native resolution of 1024x600, there is no stall on the first start, with Diablo showing black bars on the sides of the window. Must have something to do with the initial window in Diablo which starts in a different resolution than my native 1280x1024 on my desktop. It will be interesting to see what you find whenever you get around to it--no rush.

Last edited by bgc1954 (2013-02-11 20:09:18)

ozar · 2013-02-11 20:52:56

Trilby wrote:

Did you say you had nvidia? Are you using the nvidia drivers or nouveau? I do have access to an nvidia machine I can try this on to see if that may be relevant. But I'm skeptical that this could matter as I *did* see it on my computer too, but just for a short time. There must be some other relevant difference.
You also suggested that the rox dialog windows were coming up as floating dialogs, right? Mine don't. File rename dialogs, for example, come up as regular tiled windows. Perhaps this is relevant in pinpointing the difference.

Yes sir, nvidia gtx 260, using the official nvidia drivers only. I feel fairly certain it is elsewhere since I have no graphics problems with that computer unless logged into ttwm, but of course weird things do happen sometimes. Yes, some of the rox windows were coming up as floaters (some hidden behind others), but now they pretty much all come up as tiled, after some changes you made earlier I think it was.

I'm away from the ttwm machine again but will try any new code that gets pushed once I'm back to that machine in a few hours.

Thanks for all the effort going into figuring this out. Oh, and if it will help any, I'll install scrollwm to see if it happens there, as I've not ever tried that one.

ozar · 2013-02-11 23:04:48

Just got back to the ttwm machine, pulled the latest code, started rox and yippee... no colorfill of the rox window. Same goes for the windows in xarchiver and firefox, so that last bit of changes has apparently fixed it.

Thanks again for working so hard to correct the problem, Trilby!

Trilby · 2013-02-12 00:17:48

Great, glad it's working. Thanks again for the patient testing. Now, to figure out this wine window issue ... I'm off to install diablo.

EDIT: I downloaded, installed, and tested the diablo 2 demo. No problems here. I logged out, and restarted ttwm a couple times to see if it behaved differently the first time it was run, but it still worked just as expected. I'll have to try this on my other computer in the next few days - I just tried it on my i686 iMac xf86-video-ati.

EDIT2: I do get problems if I open Diablo, then MOD+N to move to another tag. I can go to the other tag, and interact with windows there (though in the lower resolution), but when I try to go back to the tag with Diablo, it never shows back up. I used xprop and clicked on the seemingly empty space where the diablo window should be - and it is there, it's just not being redrawn. I then have to restart ttwm to be able to do anything useful. But all this only happens if I shift away from the diablo tag - it starts and runs fine otherwise.

Last edited by Trilby (2013-02-12 23:37:36)

HalosGhost · 2013-02-12 22:04:44

Hey Trilby, in looking at ttwm, I have decided I would like to switch to it from i3. There are only a couple things stopping me from doing so (and I think both are user error on my part).

The first is, I'm having trouble getting ttwm to run using inconsolata as the selected font. It builds fine, but as soon as I run it, the X server dies and returns me to the console with the error below:

[TTWM] (45:15) BadName (named color or font does not exist)

I know it's referencing inconsolata, but I've tried quite a few variations of the xfontsel (and specifying "xft:Inconsolata Medium 13" as works for i3status). It seems nothing I try works out. Any ideas what I'm doing wrong?

The second is, I've not yet found any documentation for running a statusbar (and for having statusbar icons). If some exists for the 2.0 rewrite, where should I look to find it? If it doesn't, is it planned?

Seriously, thank you for this great WM.

All the best,

-HG

Trilby · 2013-02-12 23:37:03

Thanks for the compliments. TTWM does not currently use xft font stings. (edit: the paragraph that was briefly here was "redacted" as it was incorrect). I may look into using xft fonts once everything else is stable - but if it requires much extra code or resource use it will be out the window[1]. Inconsolata is a beautiful font, but I've found there are great bitmap fonts that make the extra resource use not worth it (I use terminus).

The status bar documentation is lacking - as is all 2.0 documentation for the moment. But some information can be gleaned from sporadic posts in this thread until I get to putting together a man page. Documentation is important and will be coming, but i like to iron out most of the kinks before spending too much time on it. As an aside, if anyone knows the best ways to make man pages in latex, that would be appreciated. I can find this on my own eventually, but if anyone happens to have links handy, pass them on.

But the status input in a very small nutshell is as follows:
ttwm can be passed a single parameter that names a program or script that generates output that ttwm will read and put in the status bar. All input is treated just as the plain text it is with the exception of newline characters and curly braces {}. Newline characters end a sequence of input and trigger a redrawing of the status line. Curly brace "commands" can include the following:
{#RRGGBB} where RRGGBB is an RGB color hex code. All text or any icons from this element to the next color element will be in the color specified by RRGGBB.
{i N} where N is a number specifying an icon[2] as defined at the end of icons.h. I imagine that creative users may contribute new/additional icon sets, but the default set includes the following:
0 - clock
1 - cpu
2 - memory
3-6 speaker high,mid,low, and mute
7-10 wifi full,high,mid, and low/off
11-12 mail (filled/outline can be for newmail or no newmail)
13-18 battery full,high,mid,low,empty, and charging

If there are other useful commands I'd be happy to consider adding them - but these should be limited to displaying information. Any tools to collect or calculate the information should be in a separate program or script.

I have a template for the status bar program I use called scroller.c in the scrollwm repo of my github (link below). TTWM and scrollwm share the same status input format. This is a template that will need some modifying to work with other hardware or setups, but I hope the comments make it clear enough. scroller.c generates appropriate icons colored based on the status for CPU, mem, audio volume, wifi, mail, and a clock.

Status input can just as well be generate from bash (or any other language) scripts - but I like the efficiency of compiled status programs.

[1] I have a nearly pathological commitment to resource use minimalism. Does it make sense with modern hardware? No, probably not. But there are plenty of feature-full bulky WMs out there, mine will always remain as light as possible while still providing what I (or other users) see as the most useful features. I hesitated even in adding the bitmap/coordinate-map icons as they add about 9K of data, but they're just so useful (IMHO).

[2] Note, ttwm's "icons" are not png icons, they are simply user defined bitmaps. Icons.h includes a set that I created that I think includes the basics, but these can be modified or extended by changing the coordinate arrays in icon.h.

Last edited by Trilby (2013-02-13 00:09:51)

HalosGhost · 2013-02-13 00:43:20

Awesome, well you managed to answer pretty much everything that I need to switch. However, when I was referring to panel icons, I meant more along the lines of ones that particular programs would want to add. For instance, I use Dropbox (I'll eventually switch to OwnCloud once I get some server storage to call my own), and it puts a status icon in my statusbar automatically that lets me know its sync status. I find this extremely helpful because I keep all my academic documents backed up to dropbox, so knowing the sync status is invaluable.

From what you've said, it seems that this is not a possibility. Is that the case?

All the best,

-HG

Last edited by HalosGhost (2013-02-13 00:43:56)

ozar · 2013-02-13 00:45:54

Trilby wrote:

I've found there are great bitmap fonts that make the extra resource use not worth it (I use terminus).

Agreed... and Tamsyn is another bitmap font that looks great in status bars. It's in our community repo for anyone that wants to check it out.

Thanks for all the new info on the status bars, Trilby. I'll probably try to put one together for my ttwm this weekend.

Trilby · 2013-02-13 00:50:49

@HalosGhost
Ah, sorry, you're referring to a system tray. TTWM does not include a built in system tray and I don't imagine that I'd ever add one. If I did, it would be a separate tool. I would, however, be happy to do some tweaking to ensure that ttwm cooperates nicely with any system tray application.

I don't use any system trays myself, so I can't recommend any, but these would include stalonetray, trayer, and docker which are in the repos. I (vaguely) recall hearing good things about trayer, but would be drawn to stalonetray as it does not have a toolkit dependency.

@Ozar
Tamysyn is great, I used it for a while back when I used dwm. I also played with termiusmod which had some icon-characters.

Last edited by Trilby (2013-02-13 00:54:56)

HalosGhost · 2013-02-13 00:54:23

Ah, yes, my apologies for the failing terminology. And that's okay, my understanding is that system tray managers like the ones you mentioned offer far more functionality than how i3's tray works at the moment, so I'd probably be better off switching to them anyway.

I also took a look at the icons.h, and I'll have to play with those a bit because there's a whole set of functionality in there that I'll want to use.

Thank you again for all your wonderful work.

Ozar, thanks for the tip. I'm gonna go check it out. Terminus is okay, but I'd love to see alternatives.

All the best,

-HG

bgc1954 · 2013-02-13 19:07:46

@Trilby - Well, I've been banging my head against the wall for a day or so and I can tell you that my problems with Diablo 2 are something on my end. I reinstalled the game and applied the latest patch from Blizzard and thought I had it fixed while running openbox, but I guess I had started it once before with all the messing around. I restarted openbox and then got exactly the same freeze as I did in ttwm. I went further and tried every other wm I have installed on my desktop box and nada--they all freeze on first start of the game.

I had trouble some time back and it was something to do with nvidia and wine so I guess I'll have to research some more and see if I can figure out what I did before. Just thought I'd let you know it isn't ttwm's fault. Funny that it all worked on the old ttwm but that could just be a coincidence with a wine or nvidia update. Off to check it out further until my head is bloodied enough. Thx for trying on your end.

edit: Now, I've tried a version 1 ttwm I had saved and that exhibits the same freeze in Diablo 2, although I could swear it was working at one point. I've also tried downgrading nvidia and wine to before version 2 of ttwm and that doesn't help either. Now I'm really frustrated.

edit2: Well, I can run diablo 2 in windowed mode--append a -w to end of wine run command. Video is not rendered as well but it is playable so I guess that's the best I can do for now with the hardware i have.

Last edited by bgc1954 (2013-02-13 20:32:27)

Trilby · 2013-02-13 23:11:12

That's a bitter sweet resolution - It's not my WMs fault, but then I don't have the puzzle to solve anymore.

Have you tried the nouveau driver?

This is also bitter sweet in providing me with yet another way to waste too much time: playing a Diablo demo.

Last edited by Trilby (2013-02-13 23:31:53)

bgc1954 · 2013-02-14 16:22:12

I've used nouveau in the past and never really cared for the performance but decided to give it a shot today. The performance is alot better than in the past but still choppy in Diablo 2 when you are surrounded by enemies. It's definitely a toss up--poor, dark graphics running in windowed mode with nvidia-304xx or nice bright graphics with choppy rendering with nouveau. Nouveau also renders fonts kind of weird so I'll likely head back to nvidia-304xx.

And sorry about introducing you to the total time waster that Diablo can become.

edit: back on nvidia drivers and they are still the better option, for me anyway. I just have to start diablo, kill it and restart and all is fine. A bit of a pain but better than nouveau performance.

Last edited by bgc1954 (2013-02-14 17:00:39)

Trilby · 2013-02-15 18:43:34

I just pushed changes to add back a monocle mode. I have not yet adjusted the status/title bar function to evenly space titles when in monocle mode like ttwm1.0 did, but it should be perfectly functional none-the-less.

The next big step is to rewrite the status bar drawing function to implement this and bring back the tabs.

bgc1954 · 2013-02-15 20:04:35

@Trilby - Monocle mode is back! But I found that I couldn't get it to cycle until I added "monocle" to the static const char *tile_modes line in the config.h and then only when I cycle thru the tile modes but not with the mod1/mod2+m--actually the key commands for selecting any of the tile modes doesn't work for me here.Just me mixing up ctrl and super key. Duh!

Any plans to bring back the mod1+arrow keys for window switching and going in and out of monocle mode? I kind of liked that and of course got used to it--not a huge mod1+j/k fan.

Last edited by bgc1954 (2013-02-15 20:10:49)

Trilby · 2013-02-15 20:15:19

Ah, forgot to add it to the cycling list, but that - of course - is customizable, so you can chose which modes you want to cycle through and what order. I'll add it to the default list in the next update.

The mod1+arrow keys will also be added back to the defaults in the next push. But these to can be simply added to the keybindings and they will work, just note what these are bound to has changed since 1.0. They all should be bound to the window function and the argument tells it what to do, a first character of "f" will focus another window, then a space, and which window to focus "next", "prev", or "alt" which is for alternating between the master and top of stack windows.

EDIT: mod+up arrow can be mapped to monocle, but there is no current way to toggle in and out of monocle exactly like 1.0 did. But you could map mod+up to tile("monocle") and mod+down to tile("B_ttwm") or your favorite tiling mode to effectively replicate the same behavior.

EDIT: I just pushed a config.h update to include some of this and to add some comments.

Last edited by Trilby (2013-02-15 20:29:37)

bgc1954 · 2013-02-15 20:19:43

Thanks, something to play with until you get around to your next push.

edit: thx for the arrow stuff before I got a chance to play around--you're too fast. Almost like the old ttwm--you're getting there.

Last edited by bgc1954 (2013-02-16 04:23:29)

HalosGhost · 2013-02-16 14:59:57

Hey Trilby, I have another question for you regarding adding keymappings to ttwm. I want to add keybinds for my function keys (screen brightness, volume, etc.). The way I have these set in the .ttwm_conf.h at the moment is as follows:

#define FN1         "sudo enlighten decrease display"
#define FN2         "sudo enlighten increase display"
#define FN3         "steam"
#define FN4         "netflix-desktop"
#define FN5         "sudo enlighten decrease keyboard"
#define FN6         "sudo enlighten increase keyboard"
#define FNA         "ponymix toggle -c 0"
#define FNB         "ponymix decrease 5"
#define FNC         "ponymix increase 5"
[…]
{ NULL,             XK_F1,       spawn,      CMD(FN1)       },
{ NULL,             XK_F2,       spawn,      CMD(FN2)       },
{ NULL,             XK_F3,       spawn,      CMD(FN3)       },
{ NULL,             XK_F4,       spawn,      CMD(FN4)       },
{ NULL,             XK_F5,       spawn,      CMD(FN5)       },
{ NULL,             XK_F6,       spawn,      CMD(FN6)       },
{ NULL,             XK_F10,      spawn,      CMD(FNA)       },
{ NULL,             XK_F11,      spawn,      CMD(FNB)       },
{ NULL,             XK_F12,      spawn,      CMD(FNC)       },

This works, and ttwm compiles and runs, but the compilation throws these errors (repeated for each instance):

config.h:59:5: warning: initialization makes integer from pointer without a cast [enabled by default]
config.h:59:5: warning: (near initialization for ‘keys[9].mod’) [enabled by default]

Is there a better way of making these assignments that I just haven't thought of or discovered?

And, on a related note, it seems that ttwm fails to compile when I set a keybind for a XF86KeyName type key (XF86Eject, for instance). Is there currently a way to do this? If not, are you planning one for future release?

Thank you again for all your work.

All the best,

-HG

Last edited by HalosGhost (2013-02-16 15:00:41)

Trilby · 2013-02-16 15:31:05

The errors are from setting an integer to null. The Mod key should be 0 for those. As an example:

- { NULL,             XK_F1,       spawn,      CMD(FN1)       },
+ { 0,             XK_F1,       spawn,      CMD(FN1)       },

The XF86 keynames will work, you just have to use the X11 names of the form XF86XK_NeyName. These can be found in /usr/include/X11/XF86keysym.h. I generally just use the hex values from xev though.

Last edited by Trilby (2013-02-16 15:33:03)

HalosGhost · 2013-02-16 20:05:21

Trilby wrote:

The errors are from setting an integer to null. The Mod key should be 0 for those. As an example:
- { NULL,             XK_F1,       spawn,      CMD(FN1)       },
+ { 0,             XK_F1,       spawn,      CMD(FN1)       },
The XF86 keynames will work, you just have to use the X11 names of the form XF86XK_NeyName. These can be found in /usr/include/X11/XF86keysym.h. I generally just use the hex values from xev though.

Succinct and immensely helpful, as always. Thank you so much Trilby. As soon as linux 3.8 lands and I do a reinstall, I imagine ttwm 2.x will be my primary WM.

Thank you again!

[Edit]: On second attempt, XF86XK_Eject still fails with this error:

config.h:68:25: error: ‘XF86XK_Eject’ undeclared here (not in a function)
make: *** [ttwm] Error 1

Any further thoughts? What is the syntax for using the hex codes you mention? [/Edit]

[Edit]: Nevermind, I realized that the hex format is exactly what xev reveals in output. Thanks again for all your work, it's really quite fantastic. [/Edit]

All the best,

-HG

Last edited by HalosGhost (2013-02-19 16:40:15)

HalosGhost · 2013-02-20 17:37:01

Hey Trilby,

I have another question for you. Do you have any plans on making TTWM natively functional for Wayland (that is, not just running in a rootless X server)?

All the best,

-Hg

Trilby · 2013-02-20 19:03:41

It does seem Eject is not defined in the xlib headers - but as you figured out the hex, that should work, or if you wanted your bindings to look "cleaner" you could define a Eject code yourself (e.g., "#define EjectButton 0x1008FF64" or whatever the number actually is).

I know next to nothing about Wayland, and the little I do know has not enticed me to want to learn more (yet). So the short answer is no. However, I am always open to learning new things. If you think there would be a use for a wayland version of TTWM feel free to make that case on how it would be useful and link to some relevant documentation for what that would take to implement and I may reconsider it.

HalosGhost · 2013-02-20 22:38:19

That's a good idea regarding defining an eject code, I'll look into that.

As for Wayland support, the primary argument I'd have is that the arch devs, along with a large portion of the Linux community appears to be moving towards using Wayland. There are multiple scenarios in which Wayland will probably be a lot better than X could ever be (general latency or remote computing, for instance).

Regarding helpful documentation, the best link I've seen so far on the subject is probably this video of a talk given by a group of people who have been working on hybridizing mutter to work as a Wayland compositor.

Without knowing much about the subject, I'd make the guess that porting such a light-weight WM for compatibility with Wayland would be easier than something like Mutter, but again, I am not very well-read on the subject.

Though I would absolutely love it if this project were Wayland compatible, I fully understand that such a request probably isn't very high priority at the moment as X is clearly a much more widely-used graphical server.

All the best,

-HG

Last edited by HalosGhost (2013-02-20 22:40:16)

HalosGhost · 2013-02-24 19:36:41

Hey Trilby, I'm sorry to ask for this kind of clarification, I'm sure it must seem completely stupid. If TTWM doesn't support xfts (which is fine), then which fonts does it support? I've attempted using the xfontsel values for fonts like terminus and tamsyn (even after having /usr/share/fonts/local/ added to the font path), and everytime, the compile goes fine, but upon running TTWM, I get the error: bad fontname or color.

I'd love to use tamsyn or tamsynmod, but it seems beyond me how exactly to do so. Any and all help, as always, is appreciated.

All the best,

-HG

Last edited by HalosGhost (2013-02-24 19:36:48)

Trilby · 2013-02-24 20:16:58

Those should definitely work. I use terminus myself for ttwm. Can you post your ~/.ttwm_conf.h or whatever config.h you are using and link to it?

The font declaration in mine is as follows:

static const char font[] =  "-xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso10646-1";

sharing your full config, though, will help me check if something else may have gone wrong.

Also, can you use terminus/tamsyn in other applications, such as a terminal (e.g., `urxvt -fn <fontstring>`)? In addition to adding the "local" directory to the font path, have you rehashed the font path database?

Arch Linux

#276 2013-02-11 20:07:26

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

#277 2013-02-11 20:52:56

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

#278 2013-02-11 23:04:48

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

#279 2013-02-12 00:17:48

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

#280 2013-02-12 22:04:44

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

#281 2013-02-12 23:37:03

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

#282 2013-02-13 00:43:20

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

#283 2013-02-13 00:45:54

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

#284 2013-02-13 00:50:49

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

#285 2013-02-13 00:54:23

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

#286 2013-02-13 19:07:46

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

#287 2013-02-13 23:11:12

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

#288 2013-02-14 16:22:12

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

#289 2013-02-15 18:43:34

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

#290 2013-02-15 20:04:35

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

#291 2013-02-15 20:15:19

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

#292 2013-02-15 20:19:43

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

#293 2013-02-16 14:59:57

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

#294 2013-02-16 15:31:05

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

#295 2013-02-16 20:05:21

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

#296 2013-02-20 17:37:01

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

#297 2013-02-20 19:03:41

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

#298 2013-02-20 22:38:19

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

#299 2013-02-24 19:36:41

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

#300 2013-02-24 20:16:58

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

Board footer