Alopex: a tiling tagging tabbed window manager with fur

bgc1954 · 2013-02-10 20:54:21

Yes, now I see, the last commit was something like 17 hrs. ago so that would be the one I was using.

When I was using goomwwm, I was having lots of problems running Diablo 2 and aerosuidae was doing a little troubleshooting--although he *hates* wine. I remember trying to get some xwininfo on the screens and so I tried that here but it still throws errors about can't grab the mouse. I looked back at the goomwwm posts and the xwininfo from there may still be relevant so I'll post it here:

xwininfo: Window id: 0x1600003 "Diablo II"

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1280
  Height: 1024
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x1e00001 (not installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-0  +0-0
  -geometry 1280x1024+0+0

Diablo 2 does some weird stuff as far a resolutions go... It gives 640x480 or 800x600 intro screens and then the game screen is actually my native resolution of 1280x1024.

Both Diablo2 and Starcraft are games I bought and played in windows and installed here in Arch with wine so tough for you to troubleshoot them on your end. I have a couple other games that I got from old dos game sites but they don't do all the messing with resolution stuff at the start and run fine so I can't suggest anything but I'll let you know if I find anything else that is available and that you can troubleshoot with.

edit: Mouse bindings still work fine so that doesn't appear to be an issue unless you mean trying to resize or move the Diablo window--haven't tried that yet. I still think being able to raise a terminal after the game shows intro screens is unusual in that you'd think the game would grab the keyboard and mouse input. It shows the same behavior as in other wm's, though--the window is drawn offscreen and you can shift it to cover the screen by moving the mouse. Once you're on the game screen itself, the window is locked in place.

Last edited by bgc1954 (2013-02-10 21:01:35)

ozar · 2013-02-10 21:45:53

I'm having some kind of graphics issue where when I open the first window all is fine, but when the second window opens on the left side of the screen it wants to fill itself with the focused window border color. Moving the mouse back and forth between the two windows makes the left window switch colors, but it's still filled with the border color of orange or blue, depending on if it's focused. I was having this issue with the code from yesterday, and I pulled the master code today, but the issue continues. Cycling through the tiling modes fixes the issue until I open a new Firefox or Rox window, then it repeats itself. This doesn't seem to happen with urxvt windows. I thought the issue might be related to the fullscreen bug, but now I'm not so sure.

ozar · 2013-02-10 22:34:06

A different issue that has started happening that wasn't happening before the code was updated is that when I save, change the name of files, or delete them in rox-filer, the dialog box opens fine in the center of the screen, then when the secondary dialog box opens asking if I'm sure that I want delete the file, or if saving, that the file already exists, the smaller secondary box gets hidden behind the bigger first dialog box.

Hope all that makes sense.

Trilby · 2013-02-10 23:08:16

RE: dialog stacking:
Ah, there's an issue I can solve!

The dialog box problem makes sense and I know why it is happening (because ttwm sucks as a stacking WM). As whenever a tiled window gets focus it has to be raised, I had the tile function end by cycling through and raising every floating window so they are never behind the tiled windows. But since it just does this in sequence, floating windows will get restacked in the reverse order that they were created which leads to the problem you observe.

I've replaced the raising of all floating windows with the lowering of all tiled windows. Floating windows no longer get restacked, so they should stay in whatever order they are placed in. Try it out and see if it works.

RE: graphics issue:
I installed rox again to try to replicate the dialog issue. For some reason rox's dialogs are not floating windows for me, so they were tiled - so that didn't help figure out that issue. But a couple times I did see the graphical issue you describe where the window is filled with the border color. I could not get it to happen reliably or consistently though. When it happened, I could close the rox window and relaunch rox and it would do the same thing over and over - but other times when I would launch rox, it wouldn't happen at all. I haven't yet found a pattern as to when it will happen.

RE: wine bug:
As I have no wine programs, I cannot fully replicate this, but in playing with winectl I have found one problem. If under winectl>graphics I deselect "allow the window manager to control the windows" I get all sorts of problems just trying to run winectl - the window will immediately move to the mouse pointer location whenever the mouse is over the window ... which makes it pretty much impossible to use and it ends up flying off screen. With that option selected, however,winectl works fine. So lets start there: does winectl work for you?

I've also just downloaded a free card game that should run in wine ... I'll try it out.

I see wine comes with minesweeper too. ~~TTWM crashes whenever I close a winemine.exe window either with an Alt-F4 binding or with the window's own "X" close button. I can prevent the crash by killing the process, but that's it.~~ (edit fixed this last part)

Last edited by Trilby (2013-02-10 23:40:03)

ozar · 2013-02-11 00:23:59

Regarding the border colored filling of left window issue, the only things that I can think of to add that might help are the following:

- happens with firefox, rox, and xarchiver window
- does not happen with gpicview, leafpad, or urxvt window
- the filled window color changes according to it focused/unfocused (orange/blue) status
- only happens with the left window on the screen... have not seen it on right side
- cycling through the tiling modes with Mod-spacebar seems to clear the issue for that session

Something new happening on my end is repeated crashes of ttwm when closing apps. At first, I thought it was only closing apps with the drop-down menu option for each app, and not with the killclient shortcut, but not sure now, as it seems to be happening with both. The console errors found after ttwm crashes look like the following:

Major opcode of failed request: 12 (X_ConfigureWindow)
Resource id in failed request: 0xa0007d Serial number of failed request: 987
Current serial number in the output stream: 988

Regarding the "dialog windows stacking" issue: that seems to have stopped now... Thanks!

Trilby · 2013-02-11 00:40:14

The bordercolor filling is still a mystery, but the crashes on window closes were probably from a very short-lived problem that I created while trying to solve the floating window issue. I realized the horrible problem right after I pushed it to github, then I fixed it with a new push. I'm guessing you must have cloned it right in that intervening time as those crashes are the exact symptoms. If you wouldn't mind trying a new build to see if that is actually fixed, that would be helpful.

Thanks also for all the patient testing.

ozar · 2013-02-11 00:55:24

Yes, the repeated ttwm crashing has stopped. Thanks for the quick fix, Trilby!

On the border color filling, it repeats every time here if I login to ttwm, open a terminal, then immediately open rox, or firefox so that they appear in the left window. Once I start adding additional windows, the situation becomes more erratic, and the color fill changes from almost full to partial fills. Sometimes, I can also mouse over objects that are hidden under the colorfill and they then appear on top of the color. Hopefully, some of that will help. That particular issue has been rather annoying on this end so I'll keep my eyes open for any additional clues that might help.

Thanks again...

Trilby · 2013-02-11 01:08:04

I have a (weak) hunch about this border color filling issue. I've put a code revision to test it up on github, but as I only rarely and inconsistently saw this problem, I can't tell if this change has any effect. If you are seeing this issue more regularly, perhaps you could check out the new code.

ozar · 2013-02-11 01:29:35

Hello

No luck... I pulled the new code and then opened a single urxvt window, then opened rox, but still got the same colorfill. The issue continued after closing rox and trying xarchiver in its place. Thanks for trying the new code, though.

Edit: well that's weird, it seems that the issue is no longer happening with Firefox, but it does still happen with Rox and with Xarchiver. I suppose it might return with Firefox, but we'll hope not.

Experimenting with this issue, I've found a few other workarounds to get past it, that being:

- toggling the topbar OFF then back ON makes the colorfill disappear immediately from the Rox window
- toggling the bar from top of screen to bottom and then back to the top makes the colorfill disappear
- toggling the Rox window to fullscreen, then back to the left window status makes the colorfill disappear
- note that toggling the right window fullscreen then back to its right window status does not remove the colorfill.

Hopefully, that will give you more clues to work with.

Thanks for your help with it, Trilby!

Last edited by ozar (2013-02-11 02:22:13)

bgc1954 · 2013-02-11 03:07:36

Well, let's start with a new problem that I'm encountering after the latest commit. I use a weather app from AUR called conkywx and now it appears above everything, even wine apps, so it makes it problematic to run anything as this window covers sections of all apps I'm running. It's just a modified conky window that displays weather and it's set to be below all windows but ttwm isn't letting it be below now. I'd guess that any conky window might behave this way.

2nd, I don't use winectl but winecfg where you get a gui to set the wine prefs and I always allow the window manager to control the windows. The Diablo behavior is unchanged for now--I stiil have to start it twice for it to work. I did find that if I run the graphics selection in winecfg with emulation mode 800x600, Diablo starts the first time but the window is too small to really enjoy playing the game.

Trilby · 2013-02-11 03:33:56

@Ozar,
That does narrow it down a little. The "repaint" needed is triggered by either a retiling of the windows, or a redrawing of the windows. To narrow down further to which is needed we can trigger a redrawing. Do you run any status script? (probably not as this isn't really documented yet). If not, you can launch ttwm with the following line in .xinitrc:

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

This will simply put the date in the status bar, but in doing so it will trigger the draw() function every second. With this in place, open a rox window, and leave it for a second. If the window is redrawn and looks as it should, then the needed fix is somewhere in the draw() function. If it isn't properly redrawn, then the fix is in the tile() function. Let me know which, and I can dig further.

@bgc,
Yes, I created that problem. TTWM allows dialog windows to float, but those floating windows should stay above the tiled windows. The TTWM-style tiling requires tiling windows to be raised as stack windows overlap. This presents a problem as raising a tiled window can put it above floating dialog windows. So I first simply also raised every floating window at the end of the tile() function. This, in turn, lead to the problem from a few posts back: floating window stacking was messed up. I then opted for lowering tiled windows rather than raising floating ones. I quickly saw that this could put fullscreen windows below the status bar ... so I also lowered the status bar just after other windows so it stayed on the bottom.

A side-effect of this is that other override-redirect windows (like conky) which should stay on the bottom of the stack may get brought up. Clearly, none of these are optimal solutions ... but I have to figure out some method that can satisfy all of these requirements. One that would work (but I won't do) would be to keep a list of the stacking order of all mapped windows and every time a window is raised or lowered rearrange the list. This would work - but it would be slow, resource hungry, and just ugly. There is an elegant solution to be had, I'm sure ... I just don't yet know it.

As a temporary work around, I suspect the conky setting for "own_window" set to no or false (or 0, whatever it is) should avoid the problem. I'll have to sleep on this one to dream up a better way of handling the window stacking order. (EDIT: I suppose the own_window setting would not work if you want it over the status bar)

RE: wine,
Winectl was a typo, I did mean winecfg. WineHQ has a list of apps with ratings of how they work, and links to their homepages. It can be searched for various criteria. I searched for games that are either open source or free-to-use and I've tried a couple. I have not found any issues ... but none of these games tried to set a screen resolution. If you can find a open-source or free-to-use game on that site (or anywhere else for that matter), that has the same issue, I'd be happy to test it out.

EDIT: re: floating dialogs and conky,
I did away with the lowering of windows and brought back raising floating windows. This is much cleaner and has only minor problems for floating windows ... and ttwm is not a floating WM. I did, however, add a conditional so this restacking will not happen when a transient dialog window is mapped - this should avoid the problems with sequential dialogs that lead to this kludge in the first place.

Last edited by Trilby (2013-02-11 04:03:08)

ozar · 2013-02-11 04:08:01

@Trilby

No, not running any status bars at the moment.

Followed your instructions above and the clock showed up properly, but after starting Rox, it did not redraw properly. In fact, while Rox was still borked, I opened a Firefox window which took its place in the left window position and it too was again filled with the active border color, so I suppose the issue is somewhere within the tiler function. I've tried a number of other tilers recently, but haven't seen this behavior in any of them.

Thanks for trying so hard to get it figured out...

ozar · 2013-02-11 14:15:32

Continuing to experiment with border color filled windows issue, Trilby. Here are a few additional notes on it:

- on a fresh desktop, starting rox (or xarchiver) as the first app always fills the window with active border color
- when opening a second rox window, the one on the left will fill with the active border color, but rox on right side is drawn cleanly
- starting urxvt as second app moves rox window to right side redrawn cleanly; swapping the two windows leaves rox window clean
- still have never seen the issue happen on the right side of screen, it's always either fullscreen or left side only
- the issue is intermittent with firefox

Hope this helps.

bgc1954 · 2013-02-11 16:10:30

Thx Trilby. The conky issue is gone. I don't experience ozar's border color fill issue likely due to the fact I run ttwm as I did in version 1 with no borders--got used to it that way and like the aesthetics. Not a real solution unless you were used to the original ttwm and once monocle mode is back, borders aren't really necessary, for me anyway.

Last edited by bgc1954 (2013-02-11 16:12:26)

ozar · 2013-02-11 16:21:25

bgc1954 wrote:

I don't experience ozar's border color fill issue likely due to the fact I run ttwm as I did in version 1 with no borders--got used to it that way and like the aesthetics. Not a real solution unless you were used to the original ttwm and once monocle mode is back, borders aren't really necessary, for me anyway.

Hello, bgc1954

Generally, I go with a 1-pixel border but think not having it would likely be okay, too, so will try that and see what happens. At the very least it would be good to know that clears the issue on my end, too. Thanks...

Trilby · 2013-02-11 16:38:36

I'd be surprised if an absence of borders helps. I have borders, and I only saw this happen once.

From the good description of the symptoms, it only remains until the windows are retiled which forces the clients to redraw. I've tried a few clean/simple ways of forcing this redrawing, but apparently they haven't worked. I've now taken another approach and taken a more "sledge hammer" approach which had better work.

If this does work I can start streamlining it to see how small of a hammer we can get by with - but if it doesn't work, then I must really be misunderstanding what is happening.

The "sledge hammer" is now up on git. I call it that quite light heartedly as it is entirely safe and still probably lighter than what most WMs do, but it does require a repeated call to the tile function which I find unacceptable for long term use.

Please let me know if this actually fixes the problem.

ozar · 2013-02-11 16:44:45

Thanks, Trilby - I'm away from my ttwm box at the moment but will try the new code once I return to it.

Wonder why this condition only occurs with certain apps?

Will reply back after trying the updated code... thanks again.

bgc1954 · 2013-02-11 17:10:43

I still had rox on my box for some reason and have tried to duplicate ozar's problems but can't for the life of me with no borders--haven't tried the new push yet either.

Trilby: I just tried a Diablo 2 demo from fileplanet.com--just googled Diablo 2 demo--but it seems to start first time, every time so doesn't have the behavior that I experience but it will show you the resolution change stuff I'm talking about. Installing it in wine also leaves you with several windows that don't close properly but it does install fine. The video test freezes on running but you can kill it and the game still worked for me.

edit: The demo does exhibit exactly the same behavior after all. I must have started diablo once before i tried the demo. I just logged out and back in to test the new push and diablo demo doesn't start the first time after a fresh start.

edit2: Just tried your latest push and I don't have any issues with rox, firefox, etc when I set a border width.

Last edited by bgc1954 (2013-02-11 17:27:30)

ozar · 2013-02-11 17:30:18

Okay, back to my ttwm box now and Just tried bgc1954's no borders idea. Sure enough, no more bordercolor filled windows with rox, or with xarchiver.

Give me a few minutes to pull the new code from git and reset my 1-px borders and we'll see what happens with that...

ozar · 2013-02-11 17:37:00

Okay, just went back to a single pixel border, pulled the new code, and recompiled but still getting the border-colored filled windows with rox, and xarchiver... so not sure what's up with it.

bgc1954 · 2013-02-11 17:44:00

@ozar - maybe a video card issue? I'm not seeing this on my nvidia geforce 6200 running nvidia-304xx driver.

ozar · 2013-02-11 18:02:15

bgc1954 wrote:

@ozar - maybe a video card issue? I'm not seeing this on my nvidia geforce 6200 running nvidia-304xx driver.

It's possible I suppose, but I don't see the same thing with 1-px borders in any of the other tilers (about 8 of them) that I've used, and it only happens with certain apps in ttwm. Even then, it's only in the left window or fullscreen, so my guess is that it isn't hardware related.

Edit: out of curiosity, and since 0-px borders clears up the issue, I tried it with 3-px borders to see what would happen but still get the colorfills. Only when no borders are used does it correct the issue.

Last edited by ozar (2013-02-11 18:15:43)

bgc1954 · 2013-02-11 18:33:56

@ozar - you're likely right there. Somehow the use of borders borrowed from scrollwm is causing some problem on your end but I don't know why I don't see this when I use borders here. Good thing I don't like borders it seems.

ozar · 2013-02-11 18:45:38

Strange for sure... I might end up moving to a no borders setup, but will wait on doing that just in case Trilby wants to pursue this bug further.

I've been thinking about deleting my ttwm folder and starting again from scratch in case it's a glitch in my configs, but other than some color changes, keybinding changes, and setting the mouse to focusfollow, I've not made any changes. In fact, I remember the fills happening from the first time I logged into ttwm, and I thought at the time that it was related to the fullscreen issue described in the initial v2.0a announcement.

Trilby · 2013-02-11 19:12:48

There definitely is a real bug, and I do want to fix it. I also saw it, but only in one session; it repeated several times, but then went away and I haven't been able to replicate it again since then.

I don't know how the "sledge hammer" didn't fix it ... I'm rather baffled. The sequence of events when you open a rox (or any other window) is that ttwm receives a maprequest event. This is handled by a function fittingly called maprequest. Maprequest, in turn maps the window, then calls tile(), tile tiles the windows then calls draw().

When you see this graphic glitch, all the things you describe that fix it call the tile function, so the "fix" should be in the second call to tile() and/or draw(). So my "sledgehammer" fix was to have the maprequest function call tile(), then draw(), then tile() again (which also calls draw() again). So this should replicate all the same steps that you could fix the issue with manually ... but apparently it failed. No other code should be running, so I'm at a bit of a loss. If I could get the problem to replicate here I'd be able to do some other testing.

(edit) I figured out what other bit of code may be relevant. Both rox and firefox (and presumably xarchiver) set a bogus window size when they first create their windows, then after being mapped, they send a configure notify event to change their size. In the case of firefox I find this behavior absurd, in rox's case it makes a bit more sense as rox resizes it's window based on the contents. But in either case, this is handled by a different chunk of code in ttwm, the configurenotify() function. I'll have to look closely at that now.

Perhaps pinpointing the difference in our setups would help. I'm now running ttwm 2.0a on two computers, one a i686 iMac with open source ati drivers, the other a x64 atom netbook with intel drivers. 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.

@bgc,
Tonight I'll look into diablo with wine.

Last edited by Trilby (2013-02-11 19:29:30)

Arch Linux

#251 2013-02-10 20:54:21

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

#252 2013-02-10 21:45:53

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

#253 2013-02-10 22:34:06

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

#254 2013-02-10 23:08:16

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

#255 2013-02-11 00:23:59

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

#256 2013-02-11 00:40:14

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

#257 2013-02-11 00:55:24

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

#258 2013-02-11 01:08:04

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

#259 2013-02-11 01:29:35

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

#260 2013-02-11 03:07:36

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

#261 2013-02-11 03:33:56

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

#262 2013-02-11 04:08:01

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

#263 2013-02-11 14:15:32

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

#264 2013-02-11 16:10:30

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

#265 2013-02-11 16:21:25

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

#266 2013-02-11 16:38:36

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

#267 2013-02-11 16:44:45

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

#268 2013-02-11 17:10:43

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

#269 2013-02-11 17:30:18

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

#270 2013-02-11 17:37:00

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

#271 2013-02-11 17:44:00

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

#272 2013-02-11 18:02:15

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

#273 2013-02-11 18:33:56

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

#274 2013-02-11 18:45:38

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

#275 2013-02-11 19:12:48

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

Board footer