Alopex: a tiling tagging tabbed window manager with fur

bgc1954 · 2013-02-28 00:52:08

@HG - I don't know if it will fulfill your request but once the tabs are reimplemented by Trilby, titles in the tabs will be truncated depending on how many tabs you have open. Personally, I don't have a problem with the length of the titles but, as it is, sometimes the tab indicators, as they are now, can overlap which makes it less readable.

Last edited by bgc1954 (2013-02-28 00:52:46)

Trilby · 2013-02-28 00:54:49

Geesh, I need to step away from the computer ... it seems I never pushed my last couple of commits to github. Just did that now though. I think. Maybe I need more coffee.

@HG, ttwm takes the title directly from what the client requests them to be. Many programs have options to control the window titles, you'd have to check firefox for that. I did realize though that there is a bug in how the master title is handled: stack titles are truncated so they fit in the space available for their own tab, but aparently long titles in the master window area are not truncated at all. This can be very ugly. You can expect appropriately trimmed titles in the master client area very soon. For changing what the titles actually are though, you'd have to configure firefox.

EDIT: master region title truncation should be set.

Last edited by Trilby (2013-02-28 01:02:39)

bgc1954 · 2013-02-28 01:17:46

Yup, that did it. I now see a simple clock if I don't run my status script. Thx.

Coffee?...maybe a glass of vino to relax.

Trilby · 2013-02-28 03:14:36

Na, no wine, just more coding. I just fixed the titles so that they are properly evenly spaced in monocle mode. I have also taken the first steps towards reimplementing tabs. They are ugly, colors are not very configurable, and they don't change orientation when the bar does. These will all be addressed in time, but anyone who wants can try out the optional tabs. This change added one new variable to config.h: a static Bool "classictabs". For those that never used ttwm 1.0, these tabs are best suited to a gapless and borderfree configuration.

HalosGhost · 2013-02-28 09:58:26

Trilby, awesome work! I'm getting ready to finalize (for the current implementation) my status script. And master title truncation looks great so far!

i3-wm has been uninstalled. Now, I need to go back to that WM/DE thread poll and recast my vote…

All the best,

-HG

bgc1954 · 2013-02-28 17:53:08

Ttwm is almost back to its original self...hooray! I'm likely the only one that will appreciate the tab orientation for status bar position--when you get around to it--not too many bottom bars out there, I'm thinking. I'm finding the title running past the tab if it's long but I imagine that's on the todo list as well? Good job, Trilby.

Richjn · 2013-03-05 04:07:23

@Trilby
I've been using Arch Linux since early 2004 and if you look at my post count you can see I'm not an active forum member.
Suffice to say I'm impressed and just wanted to say thanks for your work on ttwm which is now my full time window manager (former goomwwm user)

Richard

Last edited by Richjn (2013-03-05 04:07:55)

Trilby · 2013-03-05 11:44:22

Thanks Richard. Don't hesitate to post any thoughts on anything you'd like to see revised in ttwm. It is actively being developed* and I'll consider any input from users.

*Active minus a slight lull when the day job gets really busy.

HalosGhost · 2013-03-05 11:58:26

Hey Trilby, how would you feel about adding a couple lines in the PKGBUILD to draw in a user-built icons.h like you do with the user-built conf.h?

I edited my PKGBUILD to do this anyway because I wanted the Wi-Fi signal and audio volume icons to be a little different (plus, I think I'm going to add some ethernet connected/disconnected icons in a moment). Thoughts?

All the best,

-HG

P.S., I know you're not a huge fan of Conky, but I managed to get it to format and pass to the status bar quite beautifully.

Trilby · 2013-03-05 12:08:18

That was the plan for icons.h - to make it as customizable as config.h. I should be able to add that into the PKGBUILD sometime today.

But would you mind also sharing your icons.h revisions, I could include some in the default set.

The existing icons.h was my first pass at a basic proof-of-concept, but I'm not really an artist, so I'm hoping better icons will be added by users.

I imaging ttwm could eventually be distributed with a variety of icon sets (including sizes other than my 10x10) and the desired set can be selected by changing the file included on line 8 of config.h or ~/.ttwm_conf.h. To do this, though, a variety of icon files would have to be distributed with the source code. Any unselected icon files would not be compiled into the binary, so they would cary no cost other than a slightly larger source code download.

Any full icon sets, or proposed additions to the basic set can be emailed to my email link for my forum account.

PS: I'm glad conky works - it should be able to. I have nothing against conky per-se, I'm just more comfortable in C, and for things like this, a C coded status tool will be much more efficient than a conky scripted one. But that is only relevant in my maniacal-minimalism world in which my cpu is more likely to die of boredom than of being over worked.

Last edited by Trilby (2013-03-05 12:10:42)

HalosGhost · 2013-03-05 12:25:10

Actually, both my $HOME/.ttwm_conf.h and my custom icons.h are on my dotfiles github. They're under the ttwm subfolder. The wired icons are preliminary. And I think I'll eventually try my hand at remaking the Wi-Fi icons to use the ray style that many applications use now; we'll see.

As for Conky. It's certainly true the C would be faster. But, I used to run a giant statusbar shell script and Conky showing some other information at the same time. Now, I've nixed both of those in favor of a Conky script smaller and lighter (though still kind of huge due to the conditional formatting I used) than either of them separately.

[Edit]: Unrelated feature request. Is there a way to get new windows to open in the right container rather than the left? It's what I'm used to and what makes sense to me. If there's a good reason to have them open on the left, then I'm happy to listen/read, but I haven't seen an explanation thus-far. [/Edit]

All the best,

-HG

Last edited by HalosGhost (2013-03-05 15:53:58)

bgc1954 · 2013-03-06 19:58:45

Trilby - I've found a little problem with ttwm and frostwire. You can't enter anything into the search area--can't focus that area to accept input--so it makes frostwire rather useless in ttwm. I thought it inherited some behavior from scrollwm but scrollwm works fine--so do my other wm's on my desktop. I've got the /etc/profile.d/jre.sh set for a non-reparenting wm but that doesn't seem to help either way.

Trilby · 2013-03-06 20:01:41

I'll look into this - Problems that were previously fixed with jdk6 have reemerged with jdk7, which java packages are you using?

I also just pushed an update to the tabs - they're a little cleaner looking, should properly truncate titles, and are inverted for bottom status bars. I'll still be working on making colors more customizable, and some other minor aesthetic bits, but they are almost back to where they should be.

bgc1954 · 2013-03-06 20:13:18

Using jdk-openjdk7 which replaced my openjdk6 after a recent pacman update.

I'll try out the new push, shortly. I'll let you know if anything runs amok--likely not.

Edit: Just tried out the new push and the tab orientation works just like it used to, thx. I'm finding the title still running about 2 or three characters past the tab with a long title--like using luakit and going to the ttwm forum thread. Funny thing is that if I start luakit first and go to the ttwm forum thread, the title goes a little past the tab but if I start up a terminal, for example, then the title in luakit is properly truncated. If I start the terminal first and then luakit, then the title runs just past the tab. I thought maybe it had something to do with my statusbar reserved length of 575--a little long maybe--but the runover happens or not with the example I gave you above.

Last edited by bgc1954 (2013-03-06 20:27:52)

Trilby · 2013-03-06 20:38:05

Agh, yeah, I forgot part of the title issue I was going to fix. It doesn't properly truncate the master region title - would this fit the symptoms you are seeing? The master and stack titles are handled in different parts of the same function, and I only tinkered with one of them. (EDIT This should be fixed now).

I've solved the java issues here in a ridiculously easy way: I read the proper instructions. Check out /etc/profile.d/jre.sh, there is commented line with a note saying to uncomment it for non-reparenting WMs (which ttwm is). This solved my jabref issues. Let me know if this doesn't solve the frostwire issue.

Last edited by Trilby (2013-03-06 21:00:19)

bgc1954 · 2013-03-07 01:34:14

You've got the truncation--is there such a word?--issue solved, thx Trilby.

I already tried the jre.sh uncommenting--see post #337--which doesn't help the frostwire situation, here. Glad you like learning new stuff as I'm sure this is something strange either jdk7 or the recently updated frostwire is doing.

Trilby · 2013-03-07 02:12:22

I just installed frostwire to check this out and saw the same behavior. Apparently frostwire will not accept input focus. I've added the fix and it works here.

bgc1954 · 2013-03-07 02:35:08

Perfect, I'll confirm the fix--that's what I love about ttwm--a very approachable and active developer.

HalosGhost · 2013-03-13 15:20:24

Hey all, I just added a preliminary TTWM page on the Wiki, and added it to the Comparison of Tiling Window Managers page. I think I have most of the information right, but it's a wiki, so edits are welcome.

Trilby, I know you didn't want to start documentation (or finish it, anyway) until the project reaches stable-state. So, if you want me to delete the page, I'd be happy to, but I figured it'd be good to have for users looking to try it out.

All the best,

-HG

Trilby · 2013-03-13 15:39:46

That looks awesome, thanks for doing that.

I'm all for having documentation available - I just didn't want to invest time into writing man pages if I was just going to have to change them later.

This reminded me I forgot to upload the new PKGBUILD (for custom icons) to the AUR. I've now just done this - it will check for a ~/.ttwm_icons.h file just like it does for ~/.ttwm_conf.h.

For an update of progress, I've been tinkering with multi-monitor support. Unfortunately I've realized doing this "properly" would take a substantial rewrite of some of the core bits of ttwm. So proper multi-monitor support will be a goal for an eventual v3.0. For now, though, I'm building back in the limited multi-monitor support of ttwm v1.0.

There will be key bindings to activate or deactivate an external monitor or projector, and to send/return a window to/from the external monitor. There can be only one window on the external monitor at a time, and it will be essentially be in monocle-mode there. The same window will remain there regardless of tag changes until the return function is called, or until another window is sent and replaces it.

I'll push these to git in the next couple of days once I get back to my multi-monitor set up to do some basic testing of the code.

Last edited by Trilby (2013-03-14 00:09:52)

Unia · 2013-03-13 15:47:27

Trilby wrote:

There will be key bindings to activate or deactivate an external monitor or projector, and to send/return a window to/from the external monitor. There can be only one window on the external monitor at a time, and it will be essentially be in monocle-mode there. The same window will remain there regardless of tag changes until the return function is called, or until another window is sent and replaces it.
I'll push these to git in the next couple of days once I get back to my multi-monitor set up to do some basic testing of the code.

That's exactly what I want to change DWM's multimonitor to; however I do want a "true" monocly layout e.g. having multiple windows on the second monitor. I'll be interested in seeing how you've done this, perhaps I can adapt it a bit and apply it on DWM.

Looking forward to this update!

HalosGhost · 2013-03-13 15:50:34

Trilby wrote:

That looks awesome, thanks for doing that.
I'm all for having documentation available - I just didn't want to invest time into writing man pages if I was just going to have to change them later.
This reminded me I forgot to upload the new PKGBUILD (for custom icons) to the AUR. I've now just done this - it will check for a ~/.ttwm_icons.h file just like it does for ~/.ttwm_conf.h.
For an update of progress, I've been tinkering with multi-monitor support. Unfortunately I've realized doing this "properly" would take a substantial rewrite of some of the core bits of ttwm. So proper multi-monitor support will be a goal for an eventual v3.0. For now, though, I'm building back in the limited multi-monitor support of ttwm v1.0.
There will be key bindings to activate or deactivate an external monitor or projector, and to send/return a window to/from the external monitor. There can be only one window on the external monitor at a time, and it will be essentially be in monocle-mode there. The same window will remain there regardless of tag changes until the return function is called, or until another window is sent and replaces it.
I'll push these to git in the next couple of days once I get back to my multi-monitor set up to do some basic testing of the code.

Updated the page to reflect the use of ~/.ttwm_icons.h. And don't worry about it, I've been wanting to get into editing/updating the wiki for a while now, and I feel fairly confident in my understanding of TTWM, so I figured it would be a good starting point.

As for the updates regarding external monitor support, does this mean that using multiple monitors with xrandr is not currently possible? (I do not have a monitor near me with which to test.) And, do you plan to allow support for multiple external monitors?

All the best,

-HG

Trilby · 2013-03-13 16:04:41

Currently one could manually call xrandr, get an extended desktop, and move windows over to the new space - but ttwm is not (currently) able to manage that extended desktop space, so essentially these could only be floating windows that you place on the external monitor manually. I'm working on adding some degree of control of windows placed on the external monitor.

EDIT:
After a cup of coffee and a fresh look I discovered an entirely different approach that only took minimal revisions to the current code to allow for "real" multimonitor support. I've just pushed round one of revisions for this: the window placement should all be working, but many "accessory" functions such as focusing the 'aternate' window, fullscreening, and some others will need to be revised to work in sane ways on a multi-monitor set up. The tab bar code also needs revision. But these will be easy fixes, I solved the big challenge in getting this to work today, so now I just need to finish it off over the next few days.

As a bonus, the framework that this solution created will make it easy to extend to an arbitrary number of screens (technically only up to 16, but that may be more than xrandr could handle anyways).

The task list to complete multi-monitor support is:
1) ~~add a tab bar to the external monitor for its windows and clean up the main monitor tab bar code.~~ (edit: done)
2) patch up fullscreen, and focus functions to work in useful ways with more than one monitor.
3) ~~add monitor detection at startup so "static" mutli-monitor workstations will not need an extra step upon starting the WM.~~ (edit: done)
4) fix whatever breaks as a result of the above steps
5) repeat 4.

For further roadmapping, mutli-monitor mode(s) should be the last major change to v2.0 at which point I'll just fix bugs for a while as I give another project (Slider) some much needed TLC. With any luck we can have a 2.0 release party by summer ... which will entail making a source tarball for the ttwm package in the aur and having a beer.

@Unia,

Feel free to check out any of the code, but as I take a very different approach from dwm's for multi-monitor, I don't know how/if anything here would translate well.

Last edited by Trilby (2013-03-21 22:07:36)

Baryon · 2013-03-14 10:36:56

Hello Trilby,

I was looking for a new tiling window manager and was very pleased to discover this. I agree with your design philosophy - more or less. Now I've only been using it since yesterday, but here are my initial thoughts - for what they are worth:

I notice a setting for 'focus follows mouse', but what you don't seem to have is 'focus follows click'. In other words, if I click in a window, it doesn't get keyboard focus.
You mentioned earlier that you experimented with having application icons as tabs, instead of window titles? Personally speaking, I would much prefer that. The window titles can be quite long, and all I really want to know is what application it is. And since there are no separators between the tabs, I personally find the tab bar a bit messy. I had the same thought about i3. Basically I just think that having the application icons instead of window titles would allow me to see much more quickly which applications are where.
I personally think the program deserves a cooler name than ttwm. Your other apps have proper names... There seems to be some sort of unwritten rule amongst tiling window manager developers that the name of the program has to consist of a string of consonants or numbers ending in 'wm'

I've tried a number of tiling window managers - going from musca to i3 to herbstluftwm - and I think tabs are an underused but very efficient feature. Thanks for writing this. So far, I love it.

HalosGhost · 2013-03-14 10:51:34

Baryon wrote:

And since there are no separators between the tabs, I personally find the tab bar a bit messy.

Actually, there is a setting for this in config.h. If memory serves, it's the Classic Tabs boolean. Set it to "True" to get some nice separators.

Having said that, I love the idea of using app icons instead of (or with) titles. Though, I would want that to be an option, not an enforced rule.

Trilby wrote:

After a cup of coffee and a fresh look I discovered an entirely different approach that only took minimal revisions to the current code to allow for "real" multimonitor support. I've just pushed round one of revisions for this: the window placement should all be working, but many "accessory" functions such as focusing the 'aternate' window, fullscreening, and some others will need to be revised to work in sane ways on a multi-monitor set up. The tab bar code also needs revision. But these will be easy fixes, I solved the big challenge in getting this to work today, so now I just need to finish it off over the next few days.

Awesome! I just got access to an external monitor, so I'm going to have to test this.

All the best,

-HG

Arch Linux

#326 2013-02-28 00:52:08

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

#327 2013-02-28 00:54:49

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

#328 2013-02-28 01:17:46

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

#329 2013-02-28 03:14:36

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

#330 2013-02-28 09:58:26

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

#331 2013-02-28 17:53:08

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

#332 2013-03-05 04:07:23

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

#333 2013-03-05 11:44:22

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

#334 2013-03-05 11:58:26

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

#335 2013-03-05 12:08:18

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

#336 2013-03-05 12:25:10

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

#337 2013-03-06 19:58:45

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

#338 2013-03-06 20:01:41

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

#339 2013-03-06 20:13:18

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

#340 2013-03-06 20:38:05

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

#341 2013-03-07 01:34:14

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

#342 2013-03-07 02:12:22

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

#343 2013-03-07 02:35:08

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

#344 2013-03-13 15:20:24

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

#345 2013-03-13 15:39:46

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

#346 2013-03-13 15:47:27

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

#347 2013-03-13 15:50:34

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

#348 2013-03-13 16:04:41

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

#349 2013-03-14 10:36:56

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

#350 2013-03-14 10:51:34

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

Board footer