Alopex: a tiling tagging tabbed window manager with fur

Trilby · 2013-03-14 10:59:48

Baryon, thanks for the input.

1) Focus on click may be doable. Right now, without focusfollowmouse, you can focus a window by MOD+click. The problem with allowing this behavior without holding the MOD key is that if the window manager grabs *all* mouse clicks, the client programs would never get mouse click events: you could never click on client interface elements. The only solution would be to capture all mouse clicks, but resend the events to the appropriate window. This is very doable, but I'm not sure it's worth the resource costs it would incur - the window manager should not get in the way of normal interactions with client window content.

2) I'm still considering icons for tabs in the future, but this would require scaling down the application icons a great deal - I don't know if this could ever be practical. But have you also tried "classictabs" mode? In the next push I'll make classic tabs the default. These provide much nicer looking tabs and should provide better separation between titles in the status/tab bar. These were the intended behavior, but the plain text (with underline) in the bar was a placeholder while I got the full tabs working. I've kept the placeholder as an option for now, but I may remove it and go with just real tabs soon.

3) I like the current name, sorry Suggestsions for "subtitles" or taglines would certainly be considered. WM is a handy postfix, as it is informative about what 'class' of program it is.

EDIT: follow up on #2) I would like input from the community for these potential icons. Using the icons provided by the client programs themselves would require the inclusion of a graphics library capable of scaling (imlib2 may be sufficient, cairo definitely would be) and would add a decent bit or resource use. Having a "rule" system that would add user-defined 1-color icons (like status icons) would not require any additional libs, and would add no additional resource cost except for code-space definition of the icon pixels. What are your thoughts on these options?

Last edited by Trilby (2013-03-14 11:05:46)

HalosGhost · 2013-03-14 11:56:24

Trilby wrote:

I would like input from the community for these potential icons. Using the icons provided by the client programs themselves would require the inclusion of a graphics library capable of scaling (imlib2 may be sufficient, cairo definitely would be) and would add a decent bit or resource use. Having a "rule" system that would add user-defined 1-color icons (like status icons) would not require any additional libs, and would add no additional resource cost except for code-space definition of the icon pixels. What are your thoughts on these options?

I actually love the idea of having one color icons similar to the status icons. If that could be blended with the status icon pack so that full icon-packs are an option, I would seriously consider taking the time to compile a large icon pack. But that may just be me.

On the subject of feature requests, I asked you a while ago, Trilby, though I don't think I was clear at all, if it is possible to have new windows open at the top of the stack rather than in the master section. I would greatly appreciate this option, as I'm both used to, and prefer my new tiles opening on the right/bottom, rather than on the left/top. Thoughts?

All the best,

-HG

Last edited by HalosGhost (2013-03-14 12:52:15)

Baryon · 2013-03-14 13:54:33

Thanks for your replies!

Trilby wrote:

1) Focus on click may be doable. Right now, without focusfollowmouse, you can focus a window by MOD+click. The problem with allowing this behavior without holding the MOD key is that if the window manager grabs *all* mouse clicks, the client programs would never get mouse click events: you could never click on client interface elements. The only solution would be to capture all mouse clicks, but resend the events to the appropriate window. This is very doable, but I'm not sure it's worth the resource costs it would incur - the window manager should not get in the way of normal interactions with client window content.

I understand (I think), but it does seem very strange to me that I can use an application and it will accept all of my mouse-clicks, but it won't accept keyboard input until I have focused it using the window manager. And I'm very used to being able to click a window to focus it - that's all.

I imagine that the status bar would have to be at least twice the height for application icons to be of a decent size? So yes, if you go ahead with this, it should probably be optional. The "classictabs" mode is awesome - thanks for pointing it out to me, I like this much better. Only reason I ignored it was because I thought "classic" meant it was an old feature you were phasing out or something.

Trilby · 2013-03-14 14:50:24

Yes, that option name is bad "classic" means it is the good old behavior that I had to add back to 2.0 when I did a full rewrite.

HG, the attach position suggestion had fallen off my list - sorry. I think now that should be pretty doable. Would you want to have new windows at the *top* of the stack, or at the bottom?

And I may take you up on that icon making offer. But, while I love the idea, it may not make it to the top of the todo list for a while.

Last edited by Trilby (2013-03-14 14:51:02)

bgc1954 · 2013-03-14 15:13:43

Personally, I don't find the need for icons--that's just me. I use a simple--not so simple--bash script to behave like conky would for my status and, as said by Baryon, the statusbar height would need increasing, thus stealing valueable screen space from my netbook. The idea of an option is nice for those that want/need it but I like the idea of keeping ttwm's footprint as small as possible.

Anyone interested in past click to focus discussion can look back about post #111 and on and see Trilby's dislike of "rodent-dependance" in the flesh. It was added and then redacted some time ago for various reasons--starting with firefox's strange dialog window focus behavior. I'm used to it now but do find that mapping mod1+arrow keys to move between tabs a more intuitive choice, for me anyway. Most simple tiling managers tend to rely less on the mouse and more on the keyboard, regardless, so ttwm shouldn't try to be anything else IMHO.

Glad to see that ttwm is back to it's old self and no problems that I'm encountering--yet.

HalosGhost · 2013-03-14 15:28:25

Trilby wrote:

HG, the attach position suggestion had fallen off my list - sorry. I think now that should be pretty doable. Would you want to have new windows at the *top* of the stack, or at the bottom?

If I understand the model correctly, it'd be the top of the stack. That is, if you were using the R_ttwm layout, and you had two windows open, when you open another, it would become the visible window in the stack section; whichever window you had open in the stack would be pushed to an overflow tab.

bgc1954 wrote:

I use a simple--not so simple--bash script to behave like conky would for my status and, as said by Baryon, the statusbar height would need increasing, thus stealing valueable screen space from my netbook.

If you'd like to see a fairly ridiculous conky script that utilizes TTWM's icons and functions beautifully as a status script, I have one up on my dotfiles github (see my signature).

Also, if the icons for tabs are the same style/type as status icons, then they wouldn't necessarily need a larger statusbar height at all (it would depend on the icon-pack's settings).

All the best,

-HG

bgc1954 · 2013-03-14 15:51:04

@HG - maybe it's just me, but if I was into icons, especially on tabs or other window decorations, I likely would have stuck with openbox or e17. I've kind of progressed over the years from lots of eye-candy to none and full-blown DE's to minimal WM's. Arch influence or just getting old??

HalosGhost · 2013-03-14 15:55:44

bgc1954 wrote:

@HG - maybe it's just me, but if I was into icons, especially on tabs or other window decorations, I likely would have stuck with openbox or e17. I've kind of progressed over the years from lots of eye-candy to none and full-blown DE's to minimal WM's. Arch influence or just getting old??

Actually, I'm in a very similar place. But, see the icons I'm thinking of are one-color very basically rendered. Having no text, with a small symbolic icon seems more simplistic to me than having a lot of text. But, we'll see

All the best,

-HG

Trilby · 2013-03-14 20:09:15

Cool, my window manager has spawned debates

So "true" icons (i.e., those supplied by client applications) are out. Allowing for status-style icons to be placed on tabs seems like a potential future option, but it would remain a compile time option which if not enabled would have the preprocessor excise all related code so there would be absolutely zero cost for anyone who wants the text only look.

Click to focus (without a mod key) will not be included if it requires playing middle man and relaying mouse events to clients, but I will keep this in mind if I run into a simpler way to do it at which time it may be added as a configurable option like focusfollowmouse currently is. Personally I find focus-follow-mouse behavior to be completely insane - but since that one is so easy to implement, I was happy to do it: I don't discriminate based on sanity, only on memory/cpu resource use

Baryon · 2013-03-14 22:22:30

MOD-click doesn't work for me... Is this maybe because I don't have a Win/Super button on my keyboard?

Just to explain my click-to-focus issue a bit further, here's a sample usage case. I'm writing in a text document on the left, which has focus, and there's a web browser on the right. There's an input field on the web page. I click on the input field. This gives focus to the input field... which misleads me into thinking that I can now type into it. But I can't, because the client doesn't have focus, and I end up accidentally typing into my text document until I switch the focus.

Perhaps my underlying problem here is that I use a ThinkPad, and I'm very comfortable using the TrackPoint. As I understand it, the anti-mouse culture is based on the fact that you have to keep moving your hand away from the typing position in order to use the mouse. But the position of the TrackPoint on a ThinkPad's keyboard (between the G and H keys on a qwerty layout) means that this isn't a problem, and that's why I generally find it easy to click in a text field rather than use keyboard shortcuts to focus it.

Trilby · 2013-03-14 22:52:56

MOD+click may have not worked as somehow I removed something important in some over eager code cleaning. I just put it back and pushed the change.

MOD is whatever you are using as your MOD1 key in config.h, on PCs that'd be a "win/super" key, on macs I beleive it is Command. You certainly have some key that acts as MOD1 right, if not you coudn't do much in ttwm.

The recently pushed fix should fix the mod+click focus issue, but the behavior you describe with the browser is the expected and intended (default) behavior. I particularly like that I can use the middle/click paste without changing the focused window. The focus follow mouse behavior would get what you want, but also mean the focus would always be on whatever was under the mouse.

Click to focus is not likely, unless I find a cleaner way of doing it that having to resend all mouse events to clients.

HalosGhost · 2013-03-14 22:53:27

Trilby wrote:

Cool, my window manager has spawned debates

Happy to help!

Also, just asking, but did something go wrong with the multi-monitor support? I noticed that the keybinds were removed in the config.h upstream.

All the best,

-HG

Trilby · 2013-03-14 22:56:16

Nope, nothing wrong. I renamed it though. Sorry for the mess - I originally called the relevant function "vga()" for the first draft, but that is not a great name as it may be VGA output, or HDMI, or DVI, etc. So I renamed the function "monitor()". It is otherwise similar - though I've made small adjustments that will make later expansion to more than 2 monitors easier.

HalosGhost · 2013-03-14 22:58:39

Trilby wrote:

Nope, nothing wrong. I renamed it though. Sorry for the mess - I originally called the relevant function "vga()" for the first draft, but that is not a great name as it may be VGA output, or HDMI, or DVI, etc. So I renamed the function "monitor()". It is otherwise similar - though I've made small adjustments that will make later expansion to more than 2 monitors easier.

Ahh, I totally missed the rename. I like it though!

All the best,

-HG

bgc1954 · 2013-03-15 16:20:57

Oh Trilby...something you've done lately--and I see it's alot--is giving me a strange behavior with a bottom statusbar. TTWM starts fine with the bar on the bottom but when I open any app--ie terminal, luakit, etc--the app covers the bottom bar and I get a blank bar on the top of the app. When I close the app, my bottom bar shows extra letters at the start of the bar which get covered depending on my cpu usage.

For example, my bar starts with "CPU:4%:1000Mhz, etc" and when I close the app, I get "CPCPU:4%:1000Mhz, etc" untill the cpu % goes higher and it stretches the output and covers the extra letters...if you get what I'm saying. That may be due to the app overlaping the bar and then the bar redrawing when the app is closed, I guess.

I redid my .ttwm_conf.h as I see you added exta MOD variables and the monitor support so it was just easier to start my .ttwm_conf.h with a new config.h and add my own key remapping. I don't think that would have any bearing on this problem, though?

edit: Actually, I was just adding back some keymapping that I missed and when I restarted ttwm, I noticed that the extra stuff on my bottom statusbar is appearing before I even open up an app so something is different about the redrawing of the statusbar now. I can toggle the bar to the top and then it's not empty but the extra character are still at the start of the bar.

Last edited by bgc1954 (2013-03-15 16:31:24)

Trilby · 2013-03-15 17:37:12

The faulty window placement with a bottom bar was a simple mistake that I was able to confirm and fix. That is up on git now.

I'm not sure about the other issue - I'm not sure I understand the symptom. Does it look like the background is not being properly erased before the new data is printed? That could well be - if that is the symptom I should be able to patch that up pretty quickly.

Or a similar issue may be if your status bar is changing length. This certainly is allowable, but mine never does, so I might not catch issues that come from a shorter status coming after a longer one.

bgc1954 · 2013-03-15 18:07:37

That did it--the window placement with bottom bar is fine now, thx.

The extra characters at the beginning of my statusbar are likely due to the fact that I have my cpu usage % which goes from a single digit to triple digit (1%-100%) so it does shrink and expand by a couple of characters but that's never made any difference previously. I guess you're right that the background is not being properly erased before the status is redrawn or more likely due to the bar expanding and contracting but I don't know why that would show up now and not before?

Last edited by bgc1954 (2013-03-15 18:14:37)

Trilby · 2013-03-15 19:38:32

I think I know. I should be able to patch that up fairly soon.

bgc1954 · 2013-03-16 17:50:11

No hurry, Trilby. I discovered a little trick for a workaround that actually works. I just added two spaces at the start of my script so it covers up the extra letters when the script updates itself. Not genius but inventive.

Trilby · 2013-03-17 00:09:51

bgc, this should be fixed with the last git push.

This came from a little over zealous optimizing. There is a draw() function that redraws everything, and as it was the status() function would redraw a status buffer, then call the draw function. I thought this was horribly wasteful as some of our status are updated several times per second, but windows are not moved nearly that often - so going through the full draw function every time the status is updated seemed wasteful.

I had removed the call to the draw function from status() and just had it redraw itself only. But this overlooked the fact that if the length of the status bar changes, the width of the tabs have to adjust and the whole bar does need to be redrawn.

I've now done what should give the best of both options: the status function checks to see if the length has changed, and only calls the draw function if it has.

I'm surprised no one with a dynamic status length commented on it chomping off the end of the last tab - this was also a potential side effect of not calling the draw function to adust the tabs.

----

On another note I've now officially removed the classictabs option. The tabs are here to stay, but I've removed the option to *not* use them.

I'm also curious how many users use the tilegaps and borders. If you use either of these, please let me know.

Last edited by Trilby (2013-03-17 00:11:29)

HalosGhost · 2013-03-17 00:15:49

Trilby wrote:

I've now done what should give the best of both options: the status function checks to see if the length has changed, and only calls the draw function if it has.

Sweet, recompiling now.

Trilby wrote:

I'm surprised no one with a dynamic status length commented on it chomping off the end of the last tab - this was also a potential side effect of not calling the draw function to adust the tabs.

I felt a little guilty about the number of issues I've opened on your bug tracker and just hacked up the work-around that bgc eventually discovered (I added spaces to the beginning of my statusline) rather than opening another.

Trilby wrote:

On another note I've now officially removed the classictabs option. The tabs are here to stay, but I've removed the option to *not* use them.
I'm also curious how many users use the tilegaps and borders. If you use either of these, please let me know.

I've been using the tabs for a while now, so no love lost there. I don't use tilegaps, as I avoid floating windows whenever possible, so I don't really see the appeal in them, but I do use borders, as it makes a very clear and simple indicator of which window I have focused. I don't know that I would mind if the tilegaps feature were removed, but I really would like to keep the borders around.

All the best,

-HG

tommykr · 2013-03-17 10:05:49

Hi,
I have keyboard with multimedia keys. Can I add to config.h command without modifier, but only key ?
I use i3 but TTWM look interesting Maybe it's time for a change.
T.

Trilby · 2013-03-17 11:04:00

Yes, you can, just put a 0 (zero) in the mod key column. I have this for my media keys like the following:

	{ 0,		0x1008ff11,	spawn,		CMD("vol down")		},
	{ 0,		0x1008ff13,	spawn,		CMD("vol up")		},
	{ 0,		0x1008ff12,	spawn,		CMD("vol toggle")	},
	{ 0,		0x1008ff2f,	spawn,		CMD("sleep 1; xset dpms force off")},

You can also use the XF86 names instead of the hex codes if you add "#include <X11/XF86keysym.h>" to the top of config.h.

Last edited by Trilby (2013-03-17 11:04:22)

tommykr · 2013-03-17 11:11:40

Thanks for quick answer, Trilby.
Greetings.

Trilby · 2013-03-17 11:15:01

Your welcome, any input on ttwm is gladly accepted, but recognize that while it is in a state of active development, that means it is also in an active state of breakage.

It's been a long time since anything substantial went wrong for me - but it's an almost daily occurrence that I realize "oh crap, that keybinding no longer does exactly what it is supposed to". This is especially true as I just started building multi-monitor support which has quite a few side effects that need ironing out.

Arch Linux

#351 2013-03-14 10:59:48

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

#352 2013-03-14 11:56:24

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

#353 2013-03-14 13:54:33

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

#354 2013-03-14 14:50:24

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

#355 2013-03-14 15:13:43

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

#356 2013-03-14 15:28:25

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

#357 2013-03-14 15:51:04

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

#358 2013-03-14 15:55:44

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

#359 2013-03-14 20:09:15

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

#360 2013-03-14 22:22:30

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

#361 2013-03-14 22:52:56

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

#362 2013-03-14 22:53:27

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

#363 2013-03-14 22:56:16

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

#364 2013-03-14 22:58:39

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

#365 2013-03-15 16:20:57

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

#366 2013-03-15 17:37:12

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

#367 2013-03-15 18:07:37

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

#368 2013-03-15 19:38:32

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

#369 2013-03-16 17:50:11

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

#370 2013-03-17 00:09:51

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

#371 2013-03-17 00:15:49

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

#372 2013-03-17 10:05:49

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

#373 2013-03-17 11:04:00

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

#374 2013-03-17 11:11:40

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

#375 2013-03-17 11:15:01

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

Board footer