Alopex: a tiling tagging tabbed window manager with fur

2ManyDogs · 2012-10-09 22:18:00

I installed lilyterm so I could try to answer a question about it. When I tried to use the dropdown menu to select the font, I couldn't dismiss the dialog. Let me try to find more examples.

(edit) I just tried it again, and I can make the dialog go away, but I'm left with an empty gray screen (no lilyterm).

Last edited by 2ManyDogs (2012-10-09 22:21:27)

Trilby · 2012-10-09 22:22:57

Thanks. I just installed lilyterm to try it out (and I now love urxvt even more). I see some issues with Lilyterm not redrawing when it should - though that is either due to it not responding to expose events, or (more likely) if it is a java app, there are some settings needed for java apps to redraw properly in nonreparenting WMs that I don't normally have set - I tend to avoid java, at least the of the software variety, I live on the beverage. The font dialog, however, worked just as expected here.

2ManyDogs · 2012-10-09 22:25:33

I also use urxvt, lilyterm was just for a test -- and it sounds like that's not the problem bgc was describing. Let me try a few more apps. So far I haven't been able to find anything.

(edit) ok, I can replicate what bgc is seeing. If I have firefox in monocle mode and select a file to be downloaded, the download dialog comes up full screen, but with the "save file" button grayed out and down in the lower right corner of the screen. If I switch away from the window and then back again, the entire dialog is up in the upper left corner and the "save file" button is not grayed. You're not seeing this?

Let me see if I can find any other apps that do anything like this.

Last edited by 2ManyDogs (2012-10-09 22:31:47)

Trilby · 2012-10-09 22:32:43

As a check, these dialog windows are managed like any other window, right? In other words, are they resized to fit in the same frame size as any other window would be, and do they get a tab in the status bar?

Edit: Nope, I do not get that result. In firefox my saveas dialog comes up fullscreen with all buttons available. If I switch away then back, it is still fullscreen and all buttons available. However, the size change in your dialog is relevant information - it sounds like it somehow gets 'unmanaged'.

I believe firefox uses a system default file save dialog doesn't it? Is this a gtk window for you? Can you post the output of `xprop` from one of those dialogs? Ideally try to get xprop both when it is fullscreen and shaded and after it is smaller and with buttons available.

Last edited by Trilby (2012-10-09 22:37:56)

2ManyDogs · 2012-10-09 22:42:57

Before: http://postimage.org/image/42pyxu55d/

After switching away and back: http://postimage.org/image/4ou0a772h/

I'll try to get the xprop data for you.

(edit) it's hard to get xprop for the "broken" dialog because switching away from it to start xprop and switching back makes it OK again. Here is xprop for the working dialog: https://gist.github.com/3861956

Let me see if I can figure out how to get it for the broken one.

(edit 2) ha! sleep 5s && xprop gave me just enough time to start the dialog. here's xprop for the broken one: https://gist.github.com/3861969

Last edited by 2ManyDogs (2012-10-09 22:55:22)

Trilby · 2012-10-09 22:49:40

Ah, so it is still managed - that is good. I suspect this is an issue with the _NET_WM_TRANSIENT_FOR atom which defines these dialogs as modal. It seems there is a bit of controversy in the "standards" in how these should be handled by window managers.

It seems dwm ignores this atom, but it does respond to the _NET_WM_WINDOW_TYPE_DIALOG which this window also sets. I could have ttwm respond to this ... if I can figure out a logical way to do so without implementing a full floating layer.

Well there are a couple differences. The dialog from firefox on my system includes this in xprop:

WM_WINDOW_ROLE(STRING) = "GtkFileChooserDialog

Yours does not seem to be a gtk window. Is yours a standard firefox from [extra]?

In either case I will need to fix ttwm to work with those dialogs, but I'm curious about this descrepancy.

Last edited by Trilby (2012-10-09 22:54:51)

2ManyDogs · 2012-10-09 22:52:47

Is that why spectrwm has to define "quirks" for some things (and defines one for firefox dialogs, iirc) ?

I wonder why you can't duplicate this. Have you changed anything since your last git update?

(edit) -- yes, I just have the standard firefox from extra.

Last edited by 2ManyDogs (2012-10-09 23:09:02)

Trilby · 2012-10-09 23:47:06

~~I just lifted a few lines of code from dwm as a first test of a possible solution. But since I can't replicate the problem I have no way of testing the solution.~~

I also don't want to polute the regular git code with this hackish solution (if it works I'll clean it up and make it permanent). So I put all the new code in conditional compilation blocks in the same source file. A normal git pull and build or aur build will not incorporate the potential fix. But if anyone could modify their PKGBUILD to change the "make" in the build function to "make quirks" and see if this helps any, that'd be great.

~~If it does not have any effect, please check X's stderr to see if any of my 'signpost' messages got printed.~~ (nevermind this now)

EDIT: I just partially replicated this ... only partially.

Previously I had been looking at my file chooser window as I right clicked and selected "save linked file". But left clicking on a download link does bring up the window in question. The save button is shaded, but only for a split second. Without any interaction it almost immediately unshades and is available. This repeats everytime the window gains focus - if I shift focus away, then back, the button is shaded for a split second and then becomes available again.

EDIT AGAIN: Now FULLY replicated with a pattern - please verify this pattern:
When the file type is known I get the above behavior. If I need to select a program with which to open the downloaded file, I get the exact behavior you have been describing.
For a specific example, when I am here:
http://archlinux.supsec.org/iso/2012.10.06/
The .iso file has no option to open it, and the dialog save button immediately becomes available.
The .sig and .torrent files ask for a program to open them, and here the button is not available until I switch away from the window and back.

MORE INFO: I found a pattern, so a solution should be on the way: the button is shaded until the first restacking in which the dialog has focus.

Last edited by Trilby (2012-10-10 00:13:18)

2ManyDogs · 2012-10-10 00:12:07

I tried to build this, and I think I got it, but it doesn't seem to have solved the problem. I thought it moved the dialog into a floating position in the top left corner, but that only happened once, and only the one time after I switched away and back again.

I may have done something wrong though, as I usually just use "make" and "make install" and this time make install reports "cannot stat ttwm.1.gz." So I edited the PKGBUILD and changed the "make" in the package section to "make quirks" and then did makepkg and installed the resulting package.

As for "signpost" messages, I use "startx" and I see other error messages on tty1 from X, but nothing from ttwm.

(edit) -- I see the dialog when I try to download an iso. If you go back and look at the scrots I posted, you'll see that's what I was trying to do. I'll be happy to test your fix, but it may not be tonight.

Last edited by 2ManyDogs (2012-10-10 00:16:49)

Trilby · 2012-10-10 00:28:11

Hmm, well my previous fix has become irrelevant. I've now precisely pinpointed the problem - which is good - but I can't imagine a sane solution. I just tried an insane solution, which works, so I know I've identified the problem.

The problem is that the firefox dialog window will not accept input focus immediately after it is mapped (aka drawn). If I put a sleep statement in ttwm's maprequest event handler this works fine and the dialog gets the input focus as it should. But during that sleep interval the window is not managed by ttwm ... and this is true of all windows. So a "side effect" is that when any window opens, it is first shown at it's default (untiled) size, then a moment later ttwm gets control of it and tiles it. Hence "insane" solution.

I find it hard not to see this as a bug in firefox as the dialog window registers the atom saying it can receive input focus when it in fact cannot properly accept input focus until a moment *after* it has been mapped. If a program lies to my window manager, I cannot be responsible for the outcome

(that is said mostly in jest ... I will try to compensate for this lie, but I have yet to figure out how).

Last edited by Trilby (2012-10-10 00:29:16)

Trilby · 2012-10-10 00:56:05

OK, so firefox doesn't quite lie. When the dialog is first mapped it does not actually have the atom saying it can accept input focus ... and it cannot (for some mysterious reason). The dialog window only changes it's properties to be able to accept input focus after is has already been interacted with in some way (eg clicked). I put in a partial fix which restacks the windows every time a window changes it's properties. Now if you click on the dialog, the button should become available.

I suppose this issue would not arise in any click-to-focus window manager as the click (which sets the property to allow the window to accept focus) triggers a focusing of that window. Ttwm is not click to focus, nor do I want it to be. I like being able to highlight text in one terminal and paste it into the other via middle click without having focus change from my original window.

That said, this partial fix is kind of crap. This triggers a call to the stacking function any time *any* window changes *any* property. Realy this is trivial, but I find it distasteful on principle. So, instead I'm going to make click-to-focus an option (off by default). Anyone who wants firefox download dialogs to work as expected can either enable click-to-focus, or complain to Mozilla that their dialog makes no f*(#ing sense.

Edit: I scrapped the ugly hack and pushed a click-to-focus option. Set this in the config.h. Then when the firefox dialog comes up, MODKEY+mouseclick will activate the button. For an even better solution, don't use firefox!

BTW: thanks 2ManyDogs for the ongoing testing and feedback. When I update the github webpage I'll have to add you to the acknowledgements.

Last edited by Trilby (2012-10-10 01:11:22)

2ManyDogs · 2012-10-10 01:32:32

Built, tested, and working. If I "click to focus" on the dialog it acts as if I had switched away and back again, and I have to then click the "save" button that is now in the upper left corner (there is still a visible, non-working button at the lower right). Good enough for me. Thanks for the fix.

I used luakit for many months, and dwb for several more, but I found just too many pages that didn't work well with the webkit browsers (mostly finance sites) so I switched back to Firefox.

And you're welcome.

Last edited by 2ManyDogs (2012-10-10 01:33:47)

Trilby · 2012-10-10 02:08:47

I'll probably make the click to focus option not require the modkey to be held as well as allowing the click to pass through to the client window so one click on the button would do it. But if this is a mystery solved, it's good enough for one day - such polishing of the solution can wait a few days.

bgc1954 · 2012-10-10 02:51:22

Sorry for all the firefox mess! I just installed ttwm on my netbook and it fits quite nicely. Your fix works fine with the mod+mouse_click. Personally, I look forward to your future commit without the modkey but thx for the quick response with the modkey. Sorry I wasn't available to help troubleshoot your endevours on my problem--I just like firefox--what can I say! I normally just do computer stuff in the AM. Thank goodnes for 2manydogs.

Trilby · 2012-10-10 13:31:13

Oh this is just getting messier.

I'm pretty sure this is a bug in firefox. Firefox sets the WMHINTS for that dialog to tell the window manager *not* to focus the dialog. There are different focus models that programs / window managers can use - either the window manager can manage focus of child windows like this dialog, or the program can ask the window manager to only set focus to the top level window of the program with the assumption that the client program will assign focus to it's child windows when they need it.

Firefox is in the second category. So if I ignore these hints and ttwm tries to set the input focus to the dialog window, this fails - the dialog does not accept input focus and the button remains shaded. If I honor firefox's hints it never does it's part to focus its dialog window. As a test I completely disabled ttwm's setting of input focus. Firefox never sets input focus to its child dialog window.

So, model A should work like this: firefox has focus; dialog created that can accept focus from window manager; window manager sets focus to dialog window.

Model B should be: firefox has focus; dialog created that can only accept focus from firefox; firefox sets focus to dialog window.

But firefox has some hybrid model: firefox has focus; dialog created that can only accept focus from firefox; if firefox still has focus, firefox *resets* the dialog to be able to accept focus from the window manager but firefox never sets this focus itself.

bgc1954 · 2012-10-10 17:13:12

Sorry again! You know, if it's just firefox thing people are now warned here in this post and focusing away and back again does work so click to focus is not really necessary. Like I said, midori doesn't have this problem but I do use firefox more. I don't download files much in firefox so now that I am aware of firefox's erratic behavior, it's not really a problem. If I downloaded files more often I would have noticed this sooner.

And now I bet you know more about firefox than you ever wanted to. ...and so do I.

Last edited by bgc1954 (2012-10-10 17:16:15)

Trilby · 2012-10-10 17:19:48

Yup, actually that why I'm happy to learn about errors and issues - they are opportunities to learn.

Even before you posted this I planned on "redacting" the click to focus option - sorry if anyone liked it, it is an ugly hack and it doesn't warrant the code it would take to make it less ugly. It would also admit to a rodent-dependence.

Instead I'm just adding a simple key binding to the defaults which calls the stack function. This essentially "refreshes" the current work space. I've tried it with the firefox problem, and it "fixes" it on a case by case basis. In otherwords, when you get the "dead window" effect, just hit the stack() key binding and it comes alive again. No need to switch away nor reach for the rat.

This should be up on git momentarily. (edit: done)

I also wrote up a bit more of a detailed explanation of why I ditched the click to focus and other options that came up during this trouble shooting session - but it reads a bit like a rant on my "philosophy" for ttwm so it may not be right for the forum. I will put it up on the ttwm github webpage in the next few days. That page is in need of a good update.

Last edited by Trilby (2012-10-10 17:37:52)

bgc1954 · 2012-10-10 17:45:43

That was fast and it works great. You're right, it's easier than grabbing for the mouse to focus everytime firefox f*$&s up.

Trilby · 2012-10-11 00:10:56

Update: All the tbars/statusbar/vol script stuff has been removed from the ttwm repo and moved to the Rectabar repo.

There are some very minor quirks to work out of rectabar, but as it will be replacing all the status monitor functions from tbars and formerly ttwm's build in bars, I wanted to start separating them. TTWM will, of course, still draw the status bar with workspace indicators and tabs, but rectabar is entirely optional and conky/dzen or any other info bar can be used in rectabars place.

Edit: oops! Without some of the code that was removed, the status bar is no longer updated on a timer, only when a there are client window changes that cause it to update - so the clock can fall far behind actual time. Standby, that will be fixed shortly. RectaBar is only 87 lines of code, and I'd have to put back a dozen lines of code to get clock updating back and a couple dozen are already shared between ttwm and rectabar; so I'll actually just fold rectabar back into ttwm. The net ~40 lines of code that will be added to ttwm will never execute if you use dzen or an alternate bar, so they should cost no additional resources.

It is a bit odd to develop rectabar as an offshot, have it full replace the status bars and develop independently, only to get woven back in. But through that process the code has actually become more streamlined while allowing for more flexibility.

I am once again confronted with the adage about how general solutions are often simpler and cleaner than specific/restricted solutions.

From the user's perspective, this will mean ttwm can read information directly and put it in the statusbar without any additional application. It will read from stdin rather than the root window name which constrasts with dwm. If no input is sent to ttwm's stdin, then no status bar will be drawn, you can still use dzen, and the related code will never run nor use system resources.

Last edited by Trilby (2012-10-11 19:26:14)

2ManyDogs · 2012-10-11 00:28:54

Trilby wrote:

Instead I'm just adding a simple key binding to the defaults which calls the stack function. This essentially "refreshes" the current work space. I've tried it with the firefox problem, and it "fixes" it on a case by case basis. In otherwords, when you get the "dead window" effect, just hit the stack() key binding and it comes alive again. No need to switch away nor reach for the rat.

This is a much better solution. Thanks. I don't have time to test it today, but I will get to it soon.

(edit 11 Oct) -- Built and tested. New refresh key binding works well. Thank you Trilby.

Last edited by 2ManyDogs (2012-10-11 19:21:01)

Trilby · 2012-10-11 19:27:34

Cross post-editing again. You may want to note the edit above if you use ttwm regularly ... otherwise I could be blamed for letting you run late to an appointment as the clock is (temporarily) not reliable.

Edit: the fix to this is now on github and rectabar is fully integrated into ttwm. You can just ignore rectabar completely and it will do nothing. You can leave space for another bar application. If you want to use (the now built in rectabar) just feed information into ttwm's stdin.

I'll next work on some documentation for this rectabar input format. If you like the cpu/audio/battery status bars previously in ttwm, those are now replicated by a program called "cab" (CpuAudiBattery) in the RectaBar repo on my github. I run that from xinitrc with the following:

exec dbus-launch --exit-with-session cab | ttwm

After this iteration of pruning and adding back, ttwm has become a bit slimmer overall. The inclusion of all of rectabar's functionality only added a net of 40 lines of code (only one of which ever executes if you don't feed info into ttwm's stdin).

An interesting option this provides, is that one could make a fifo and feed it to ttwm's stdin, then push various data to the fifo at runtime from various sources to have a general purpose notification system with colors and shape drawing abilities. This was never the intent, but I realized it's a pretty cool possibility.

Last edited by Trilby (2012-10-11 22:36:16)

bgc1954 · 2012-10-12 18:00:24

Don't know what happened but I just rebuilt ttwm and now it's pushing my cpu to the max. I tried running without conky/dzen also to make sure that they weren't interfering with built in rectabar but makes no difference. CPU maxed out.

Edit: tried commenting out all the rectabar references from ttwm.c and rebuilding but that doesn't seem to help either.
But I see from your commits that there's more to it than just commenting out rectabar references. My knowledge of C is still very small.

Edit2: It's got something to do with the last lines "XEvent ev" stuff. When I commented out the last bits you added in the ttwm.c--starting at line 603--ttwm doesn't hog my cpu anymore. What that stuff does is a mystery to me but that seems to be where its running away with itself.

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

Trilby · 2012-10-12 19:17:08

Are you piping anything into ttwm's stdin?

Starting at line 603 is the main event loop. If you comment that out ttwm should not do anything at all - it will just exit and your X session will end. The while loop at line 610 listens for input from the stdin stream and from the X server (events such as key presses).

As a first troubleshooting step, uncomment everything (ie take the code as is from get) and just delete the call to "rectabar()" on line 618 but leave the if statement and the trailing semicolon.

If this still gets cpu issues, then it shouldn't have anything to do with the rectabar code.

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

bgc1954 · 2012-10-12 19:24:00

Nope! Just running ttwm by itself. I mostly just reversed your commits a bit at a time and from what I remember nothing made a difference until I commented out the last stuff and put back in the lines that were there. Like I said, just commenting out rectabar stuff didn't help so I started reverting everything back a little at a time and it was the last bits or maybe the stuff just above when my cpu went back to normal.

Edit: I'll try your suggestion now and report back. I didn't comment it all out. I put back in lines 556 & 557 so I didn't get kicked back out, I guess.

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

Trilby · 2012-10-12 19:26:30

Are you using a custom config.h? Have you tried the default?

Arch Linux

#101 2012-10-09 22:18:00

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

#102 2012-10-09 22:22:57

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

#103 2012-10-09 22:25:33

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

#104 2012-10-09 22:32:43

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

#105 2012-10-09 22:42:57

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

#106 2012-10-09 22:49:40

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

#107 2012-10-09 22:52:47

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

#108 2012-10-09 23:47:06

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

#109 2012-10-10 00:12:07

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

#110 2012-10-10 00:28:11

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

#111 2012-10-10 00:56:05

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

#112 2012-10-10 01:32:32

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

#113 2012-10-10 02:08:47

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

#114 2012-10-10 02:51:22

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

#115 2012-10-10 13:31:13

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

#116 2012-10-10 17:13:12

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

#117 2012-10-10 17:19:48

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

#118 2012-10-10 17:45:43

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

#119 2012-10-11 00:10:56

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

#120 2012-10-11 00:28:54

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

#121 2012-10-11 19:27:34

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

#122 2012-10-12 18:00:24

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

#123 2012-10-12 19:17:08

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

#124 2012-10-12 19:24:00

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

#125 2012-10-12 19:26:30

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

Board footer