Alopex: a tiling tagging tabbed window manager with fur

Trilby · 2012-12-10 17:06:54

I still cant replicate the pcmanfm behavior on my other computer either. It works just as would be expected for me.

The only way the dialog window should go into tiling/monocle mode is if you hit Mod and mouse button #2.

Can you check with xev and verify that your mouse buttons give the expected values:
Left: Button 1
Middle: Button 2
Right: Button 3

bgc1954 · 2012-12-10 18:55:39

Something I've done just lately has everything working with whatever changes you last did. Now pcmanfm rename, etc. comes up with a nice dialog box with highlighted text in grey. It works fine to change text and then press ok. If I click on it with mod+mouse_button_1 it just changes the highlight color to blue as I expect and functionality is the same. I'm not sure if I tried this after you applied the sizing hints so that's likely what did it.

All my mouse buttons work properly mod+button1-move window, mod+button2-back to tile, mod+button3-resize window.

The only issue is that opening up an mp3 from pcmanfm still does what I reported last. You get a gnome-mplayer window that doesn't show a title or progres bar until you mod+mouse_button1 click on it and move the window--just mod+mouse1 click doesn't give you the proper window. Then all comes back to what I would normally see. Not something I do alot anyway. Now back to playing with scrollwm.

xens1x · 2012-12-12 03:12:23

Is there a way to change the clock using something like xsetroot? I've found the function in the source for the clock, but I'm at a complete loss as to what to do next. Is this something you've ever considered implementing? Do you have any tips on what to do to get it working?
If you don't want to help, it's no big deal, I'll figure it out eventually.

Trilby · 2012-12-12 03:30:38

@BGC, I'm glad by completely ignoring your problem helped fix it. Perhaps I'll completely ignore the remaining problem in hopes of the same result (kidding of course).

@xens, There is no way to currently change the clock, but I have been considering removing all of the status bar except for the tabs and allowing the user to customize all that information through the 'rectabar' input. What, specifically, would you like to change about the clock? It would be very easy to do the first step in my plan to offload all of this to external tools: I could remove the clock, move the workspace indicators flush to the left edge, and allow more space for user-status information.

TTWM doesn't read from the root window name. I love dwm, but I can't help but wonder why on earth the suckless team made that choice: that is a ridiculous way to pass data between programs especially when the *nix world has been thriving on standard streams since the very beginning (except for when XDM breaks them, aparently). TTWM reads from it's stdin. More information about this can be found in the RectaBar repo on my github as that tool was incorporated into ttwm.

Long story short, you can feed whatever kind of clock data you want in currently. I even implemented a funny looking binary clock. But then it would be redundant with the default clock. So I can just remove the default clock and leave time display to the user scripts.

xens1x · 2012-12-12 03:37:56

Trilby wrote:

@xens, There is no way to currently change the clock, but I have been considering removing all of the status bar except for the tabs and allowing the user to customize all that information through the 'rectabar' input. What, specifically, would you like to change about the clock? It would be very easy to do the first step in my plan to offload all of this to external tools: I could remove the clock, move the workspace indicators flush to the left edge, and allow more space for user-status information.
TTWM doesn't read from the root window name. I love dwm, but I can't help but wonder why on earth the suckless team made that choice: that is a ridiculous way to pass data between programs especially when the *nix world has been thriving on standard streams since the very beginning (except for when XDM breaks them, aparently). TTWM reads from it's stdin. More information about this can be found in the RectaBar repo on my github as that tool was incorporated into ttwm.
Long story short, you can feed whatever kind of clock data you want in currently. I even implemented a funny looking binary clock. But then it would be redundant with the default clock. So I can just remove the default clock and leave time display to the user scripts.

Essentially I want to add some other information such as battery life, now playing, temperature etc . I have already figured out how to get rid of the clock, but I still want it there.
What do you think will be the most efficient way to do this? A system call? I can do battery/temperature with C, but integrating with mpd would be tough.

Trilby · 2012-12-12 03:43:04

You should really use the rectabar input for this, that's what it's for. See "cab.c" on the rectabar repo as an example that displays 3 meters for CPU, Audio volume, and Battery.

I launch ttwm with cab from .xinitrc as follows:

exec ttwm /path/to/cab

Again, I'd suggest starting with cab.c to get any idea of how it can work, then modifying it to include other information you want. This can be text, or rectangles that can make meters and you can assign any RGB color values you want.

Rectabar is not well documented as it was abandonded as a standalone tool when it was fully integrated into ttwm. But the rectabar repo has some information and several examples in both C and shell scripts.

Last edited by Trilby (2012-12-12 03:44:26)

bgc1954 · 2012-12-12 17:52:28

Since someone else requested it and you seem to be considering it, I'd vote for abandoning the clock too. I could put it in my status.sh script--the date is already there--and then I could get away from that 24 hr clock stuff. I worked shiftwork for almost 30 years and the 24 hour clock is not my friend--brings back bad memories.
I never really thought about requesting it though.

bgc1954 · 2012-12-30 20:03:58

Trilby - I have been trying out the gweled game in extra repo--basically a bejewelled clone. Ttwm seems to have a problem focusing still, for me. The game starts and you can't make a selection of type of game until you mod+mouse1 and actually move the screen. Then after game selection there is no game window until you mod+mouse1 and move the existing window and then the game appears. Also when you quit, the save game dialog appears behind the game window and you have to move it out of the way to select yes or no. This also happens if you get a high score, the dialog comes up behind the main window. Maybe a quirk in the game itself? The game has crashed a couple of times and I got an .xsession-error

======== TTWM ERROR ========
request=12; error=3
BadWindow (invalid Window parameter)
============================
======== TTWM ERROR ========
request=42; error=3
BadWindow (invalid Window parameter)
============================
Audio driver choosen: ALSA
/bin/bash: line 1: 27084 Segmentation fault      gweled

I've also experienced this type of thing mostly with gnome-mplayer where you have to mod+mouse1 and move the first window to get the window that has the stop/start/pause controls. I've seen it elsewhere occasionally on dialog windows but I can't recall specifics right now. You seem to be able to get them back using mod+mouse1 and moving the window. I'll try to post specifics when and where they happen.

Last edited by bgc1954 (2012-12-30 20:22:54)

Trilby · 2012-12-30 21:31:59

I'll try to look into this, but I'm actually thinking about recoding ttwm from scratch. I have learned a good handful of new tricks with my scrollwm excursion, many of which would be useful for ttwm. Some of these would be hard to incorporate without changes in a bit of the "core logic" of ttwm.

So I think I'll delay the 2.0 timeline a bit and do a substantial rewrite that will avoid some of the wm-newbie kludges that I used in ttwm. The intent will be to get the same end result for the user, but with much less metaphorical duct tape to deal with the snags that occasionally hinder the current ttwm.

Because of this plan I will not likely do much more fixing up of the current code (except to remove the clock which I'll do momentarily (edit: done)). But I'll put a goal of the end of January for the rewrite which should avoid most of these problems.

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

bgc1954 · 2012-12-30 22:10:33

Good to hear that ttwm is getting a new incarnation--not that there was much wrong with it now. Look forward to seeing how the reborn edition works. Thx for the clock removal, I just have it in my status.sh script now.

bgc1954 · 2013-02-02 19:04:02

Hey Trilby - just wondering if you're making any progress on rewriting ttwm?

Trilby · 2013-02-02 19:38:37

Eh ... I missed my own deadline.

Yes, I am making some. All the git commits have been on ScrollWM, but that's because I'm "rebasing" ttwm on scrollwm. Now that most of the bugs are out of scrollwm, I'm going to copy over a lot of the code - but remove all the scrolling and animation stuff to get it acting like ttwm does. It's been a busy month at the day job, so I'm not sure exactly when this will be coming.

bgc1954 · 2013-02-02 19:54:36

Like I said, just wondering. For me, goal setting is highly overrated anyway--my old job forced goal setting to get pay hikes and the goals were generally unattainable and often not paid out as the company also linked the pay to corporate profits which they seldom achieved...hmmm. It's not like you're getting paid. Patiently waiting on this end. Thx for all your effort.

Trilby · 2013-02-02 20:00:03

"Goal" is an odd work. It was more of a rough plan just to keep ttwm users informed.

Trilby · 2013-02-09 23:16:50

Just a brief note (for now) to mention that I just pushed the newly rewritten from scratch 2.0 (very "alpha") version to git.

All the functionality of ttwm-1.0 should still be maintained, but many of the implementations have been improved, and thus key bindings are revised and any previous custom configs (~/.ttwm_conf.h) will have to be rewritten. I suggest discarding them, grabbing the 2.0 default, and adjusting from there.

The stdin reader (for the status line) has ditched the {r ...} rectangle functions, but has gained {i #} icon functions. This is inherited from scrollwm and some documentation can be found there - or just wait until I get around to putting some here. Plain text will still be read just fine as plain text.

Ttwm also aquired the tilegap and border settings from scrollwm - but these can be configured (set to zero) to replicate the 1.0 look and feel.

I know of one current bug with fullscreen windows. It is only encountered if you fullscreen a window then try to switch focus away before "unfullscreening". It will be fixed eventually, but for now, just don't do that.

Last edited by Trilby (2013-02-09 23:20:06)

ozar · 2013-02-10 02:19:57

Trilby wrote:

I just pushed the newly rewritten from scratch 2.0 (very "alpha") version to git.

Hi, Trilby

I've been playing around with various tilers for a couple of months now and while I never got around to trying the previous version of ttwm, this new version looks like it might be just what I've been looking for!

It's installed, up and running, and I'm posting from it now. Will be reporting back with any issues and/or feedback.

Thanks for authoring it.

ozar · 2013-02-10 15:51:15

Re: v2.0a

Each time after quitting ttwm, I'm seeing the following error messages on the console:

=TTWM ERROR=
request 12 error 3
BadWindow (invalid window parameter)

Then the same error repeats itself two more times but with 'request 2' and 'request 42'

Not certain, but I'm thinking that might be happening after I've cycled through the tiling modes, which I've been doing to get past the fullscreen bug mentioned above. So far, that's the only bug that has really jumped out at me.

Is there a way to set the initial size of master windows like in dwm, monster, awesome, etc? I've checked config.h but didn't see the option there.

I like it... thanks again for your work on this, Trilby!

Edit: oops, just noticed basically the same window errors were posted by someone else above that was using the previous ttwm release. Sorry for posting duplicated bugs.

Last edited by ozar (2013-02-10 15:53:42)

Trilby · 2013-02-10 16:25:06

The master window size is set by "tilebias" in config.h. It is adjusted at runtime with default bindings Mod+i or Mod+d (inrease/decrease) but can also be set at the desired starting point in config.h (requiring a recompile). The PKGBUILD will check for ~/.ttwm_conf.h and if it exists it will use that in place of the default config. You can, thus, copy the default config to ~/.ttwm_conf.h and adjust settings which will be maintained if/when you update ttwm-git.

In the previous version the tilebias was a float (fraction) of the screen. Now it is an integer number of pixels as an offset from half the screen. So if tilebias=10 the master window will be half the window plus 10 pixels and the stack will be half minus 10 pixels.

The errors are from the xerror handler. They are just verbose output from Xlib that is passed on by ttwm incase there is a problem. If there is a problem these will help identify it. If there is no problem, however, I wouldn't worry about them. Other WMs (dwm as a specific example) ignores a vast majority of these errors/warnings silently. I just prefer ttwm to be more verbose so the user has the information needed to track down the source of any problems that arrise. Perhaps I'll change "TTWM ERROR" to "TTWM WARNING" to alleviate concern to this unfamiliar output.

Last edited by Trilby (2013-02-10 16:37:30)

ozar · 2013-02-10 16:38:01

Perfect... thanks for the quick reply and info.

I was wondering about tilebias but hadn't seen that option in the other tilers that I've tried.

bgc1954 · 2013-02-10 17:26:25

WOW! What a reincarnation. It certainly shows its scrollwm heritage. Good news is that the dialog window problems of the past--so far--are gone. I like the way that youtube videos can go fullscreen and automatically cover or remove the statusbar like in scrollwm. I've just been playing with it for a short while but haven't stumbled upon anything out of the ordinary, yet. I haven't noticed the fullscreen bug but I have a tendancy to not do that behavior anyway so I'm okay. I'll have to do it on purpose so I see what you're talking about.

It's not really Tiny Tiler/Tabbed tiler WM anymore--any thoughts to bringing back the tabs? It's an aesthetic that I got used to and like. Gives more separation to the opened windows and if you have a few open it looks a little crowded on the statusbar now.

Is monocle mode gone? I kinda got used to exclusively using monocle mode and only using one desktop moving around in/out and app to app with the arrow keys. Will that functionality return or will I be learning a new behavior using separate tags as I find myself doing now?

All in all, ttwm's functionality seems improved but it doesn't quite look like itself anymore.

Thx for all your effort and I'm sure if I could understand all the code, it has been improved considerably.

Last edited by bgc1954 (2013-02-10 17:27:28)

Trilby · 2013-02-10 17:53:41

The fullscreen "bug" is partially fixed -- perhaps completely fixed, but I need to do some more testing.

I did opt for a different look for the tab bar mostly for simplicity as a temporary place-holder. I'm planning on playing with the aesthetics of it a bit to bring back the tabs, but for a first run it was simpler to just have titles floating in the bar. It will be pretty easy to add back tabs once I decide on a look that can work well with various modes. I may even put in an option for one of two different looks. It still has tabs ... just now transparency!

Monocle mode is only temporarily gone. I wanted to get the code up for some testing once it was functional, but there are several bits that have yet to be added back in. Monocle mode, and external monitor support top that list.

Last edited by Trilby (2013-02-10 17:55:12)

bgc1954 · 2013-02-10 18:21:03

Great! I knew it was a first draft but just thought I'd ask. I seem to be having strange behavior with some wine games that didn't occur before. They appear to start and show in htop that they're running but don't appear onscreen. I've looked for errors and logs but haven't found any yet. Sometimes I can get them to start using a terminal and then they'll start with dmenu fine after that. I don't see a pattern yet and it's early so I'll report back if I find anything concrete.

edit: Just noticed that the hide bar and toggle from top to bottom, mod+a and mod+x, got switched--no big deal, I'll just change them in my .ttwm_conf.h to what I was used to--or maybe it's just me? What can I say, I'm a creature of habit.

edit2: Just some info, whether or not it is helpful or fixable. I'm finding that if I try to play Diablo 2 thru wine it does not start--inherited form scrollwm as I just tried it there and it shows exact same behavior (ttwm never had this problem). I see it trying to start as it shows a flash of small numbers in the upper left corner of the screen--this is normal--and then just stops with a white rectangle and no intro window is shown. If I go to htop, I can see it's running and I can kill it from there. If I restart Diablo 2 again thru dmenu, it starts normally.

If I start Starcraft with wine from dmenu it shows nothing in htop and doesn't appear to start. I can try to restart it as many times as I want but it won't start. If I start Diablo 2 and do the above--starts on second try--I can then start Starcraft. I can also start it if I start from a terminal. Both will then start and work but as soon as I log out and back in, I have to start, kill, then restart Diablo 2 from dmenu or start Starcraft from a terminal the first time. These older games start intro screens in different sizes than native resolution and other wm's I have tried in the past had trouble dealing with that. The original ttwm didn't have any problems so I don't know what it inherited from scrollwm that would affect this. If you're not a fan of wine I understand--you're not the only one.

Last edited by bgc1954 (2013-02-10 20:14:55)

Trilby · 2013-02-10 20:10:49

Oops, yes, those key bindings were just backwards when I put them in. I'll change the default config, but this can - of course - be customized.

RE: wine apps: I had odd behavior for a bit with windows that start floating (eg transient windows like popups and dialogs). When I checked the window properties before they were mapped (displayed) they were requesting large negative x,y coordinates for their position. Before I knew what was going on, I honored these requests and dialogs seemed to not appear - they were appearing, they were just far off screen. This problematic code was the first push to git for 2.0 - I have since updated to fix that problem, but I wonder if the wine window issue could be related.

A couple checks: when one of these windows opens successfully/properly can you run xprop on it and post the output, do dialog windows show up centered on the screen (eg web browser file download dialogs).

bgc1954 · 2013-02-10 20:20:49

My edit2 was a bit long and I took some time trying to word it--I see you already responded to my original post--you're too darned fast.

I'll try the new update and report back. To answer your other question, I did notice that dialog windows now appear in the centre of the screen instead of the old top left corner behavior and they don't appear to have any focus issues that I can see, yet. I'm off to see if your update addresses any wine issues.

edit: I see that it isn't up on git yet--now I'm too fast. I'll let you know after your next commit.

edit2: xprop doesn't work. Funny enough, I can start a terminal and issue xprop but it throws an error "can't grab the mouse".

Last edited by bgc1954 (2013-02-10 20:29:33)

Trilby · 2013-02-10 20:29:41

Actually, it is up on git - if the dialog windows were working that means you got the code after the fix was pushed which in turn means this wine-window issue is a separate problem. Just the same, xprop output from one of them could be helpful.

As a bit of an aside, I have no issues with wine and would like to have my WMs working with anything users may want to run. I just don't currently have wine or any wine programs installed to test this out on. Can you suggest a wine game/program that would be easiest to install to replicate these issues? Are any of them in the repos, or are they all AUR? Or do you have them only from previous windows install media? (edit: installed wine itself, now I need candidate programs to run).

EDIT: I just tried launching from XDM as display managers will change many things - but I can't replicate the xprop issue. If there was a mouse grab that didn't properly release the mouse this might explain some of this. To test, do mouse bindings work? Mod+button1 drag should move a window. If this fails this would likely be the problem.

Last edited by Trilby (2013-02-10 20:47:41)

Arch Linux

#226 2012-12-10 17:06:54

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

#227 2012-12-10 18:55:39

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

#228 2012-12-12 03:12:23

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

#229 2012-12-12 03:30:38

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

#230 2012-12-12 03:37:56

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

#231 2012-12-12 03:43:04

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

#232 2012-12-12 17:52:28

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

#233 2012-12-30 20:03:58

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

#234 2012-12-30 21:31:59

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

#235 2012-12-30 22:10:33

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

#236 2013-02-02 19:04:02

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

#237 2013-02-02 19:38:37

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

#238 2013-02-02 19:54:36

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

#239 2013-02-02 20:00:03

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

#240 2013-02-09 23:16:50

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

#241 2013-02-10 02:19:57

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

#242 2013-02-10 15:51:15

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

#243 2013-02-10 16:25:06

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

#244 2013-02-10 16:38:01

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

#245 2013-02-10 17:26:25

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

#246 2013-02-10 17:53:41

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

#247 2013-02-10 18:21:03

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

#248 2013-02-10 20:10:49

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

#249 2013-02-10 20:20:49

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

#250 2013-02-10 20:29:41

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

Board footer