Alopex: a tiling tagging tabbed window manager with fur

Trilby · 2012-08-11 18:27:48

----ORIGINAL ANNOUNCEMENT BELOW (No longer accurate; for history only) ----

github wepage wrote:

TTWM is a minimal tiling window manager combining concepts or elements from TinyWM, DWM, and i3wm. Inspiration has also been drawn from other great tilers like MonsertWM. TinyTiler is currently under 500 lines of code. In contrast to other tilers, TinyTiler does not have layouts, it does not have modes, and it does not have window rules. These choices were by design. TinyTiler instead gives you two screen sections, the "master" on the left half of the screen, and the "stack" on the right half. In TinyWM only one stack window is visibile at a time, the others have tabs in the statusbar.

Check back on this thread for updates and to report bugs, ask questions, or request features.

-----END ORIGINAL ANNOUNCEMENT-----

(Older irrelevant edits removed)

EDIT (17 May 2013): Hopefully the name change in 2.0 development has been obvious, but just in case, ttwm is now alopex. Also, as 2.0 has been released as a stable versioned tarball ("stable" being perhaps only an honorary title rather than an apt description) the 1.0 tarball will soon be removed from github. If anyone finds sentimental value in keeping old tarballs around (in mothballs perhaps?) then grab it while you can.

EDIT (2 July 2013): There is now only one AUR package: alopex-git.

EDIT (29 Nov 2013): There will be major changes as version 3 comes out. See the discussion for that starting here.

EDIT (13 Feb 2014): 4.0 is coming along well (3.0 was D.O.A). I've removed "Tiny" from the description, as while alopex is still small and resource light compared to some WMs, the inclusion of cairo makes it not as tiny as alopex's ancestor TinyWM.

Last edited by Trilby (2014-02-13 23:16:59)

litemotiv · 2012-08-11 19:13:59

Typing this from TTWM.

2ManyDogs · 2012-08-11 19:41:33

I'm also running it now. Nice work.

(edit) I just finished reading the README (after I built and installed the WM, of course ) And I agree with a lot of it. I usually use ratpoison, and mainly full screen. When I want to see more than one window, however, I split the screen along the vertical axis, so I have one frame above and one below. Usually I keep the top frame on one window and switch windows in and out of the bottom frame. I almost never use more than two frames. I split top and bottom because I don't have a widescreen monitor and I like to be able to use the full screen width for each frame. When I use DWM, spectrwm, or monsterwm, I set the default to "bottom stack."

I'm not asking you to add vertical split to ttwm (unless it's easy ), just explaining how I use tiling WMs, and agreeing that two open windows is enough.

I'm happy you based it on tinywm. It's one of my favorites: http://crunchbanglinux.org/forums/post/205966/#p205966

Last edited by 2ManyDogs (2012-08-11 20:07:46)

Trilby · 2012-08-11 19:50:51

Cool, thanks. I look forward to hearing what breaks first

edit: for the following reply.

Thanks for the feedback 2ManyDogs. I suspect having a horizontal rather than vertical split should be fairly easy. I'll mull it over and try it out. I suspect it would only require one additional variable plus one or two conditionals in the stack function. (edit: this change is now up on github and in aur)

But so much for the no layouts idea then!

I'm curious though, while the stack function and window management aspects should be easy to change, would you have any suggestions on the aesthetics of the status bar for this option? With a right-left split the stack window tabs are right over the stack windows in an intuitive place. With a top-bottom split, you'd have tabs on the right side of the screen for the stack windows that are on the bottom. Functionally this would be fine, of course ... but I just wonder if there'd be a better design for that.

FYI, one thing not mentioned in the readme is that I will be adding a size/proporiton variable so the master and stack won't have to be set strictly to half the screen.

Last edited by Trilby (2012-08-12 21:15:46)

2ManyDogs · 2012-08-11 20:48:03

Trilby wrote:

Thanks for the feedback 2ManyDogs. I suspect having a horizontal rather than vertical split should be fairly easy. I'll mull it over and try it out. I suspect it would only require one additional variable plus one or two conditionals in the stack function.
But so much for the no layouts idea then!

That's why I didn't really ask for it -- you should keep it tiny and don't let people convince you to add bloat (especially not window borders!). I'm not attached -- I'll probably continue to use ratpoison, unless an overwhelming number of other people vote for the vertical split (I hate this terminology -- it makes more sense to call this a horizontal split, because the line is horizontal, but ratpoison and musca call it a vertical split, because the frame is split along the vertical axis). I'm always playing with different window managers on a test machine, so I expect this will make its way onto one of them eventually

I'm curious though, while the stack function and window management aspects should be easy to change, would you have any suggestions on the aesthetics of the status bar for this option? With a right-left split the stack window tabs are right over the stack windows in an intuitive place. With a top-bottom split, you'd have tabs on the right side of the screen for the stack windows that are on the bottom. Functionally this would be fine, of course ... but I just wonder if there'd be a better design for that.

I can't think of anything right now, other than the way WMFS has a tab bar in the middle of the screen if you have tabs below. I don't particulary like this; it wastes screen space. I think keeping the tab indicators at the top of the screen is fine -- it still lets a user know there are multiple windows in the tabbed area.

FYI, one thing not mentioned in the readme is that I will be adding a size/proporiton variable so the master and stack won't have to be set strictly to half the screen.

This is good news -- it will be an excellent adddition. Will it be set at compile time only or adjustable while the WM is running? I wasn't going to ask for this -- judging from the monsterwm and snapwm topics there will be plenty of other people asking for features.

Last edited by 2ManyDogs (2012-08-11 20:55:55)

Trilby · 2012-08-11 21:40:17

Good news, I realized that having a "bottom stack" mode will be ridiculously simple. In fact the bottom stack and adjustable size of the "master" area will use the same mechanism: just a couple ternary operators in the arguments to XMoveResizeWindow in the stack function. As is often the case the general solution is easier to implement that the specific solution, so asking for the new feature actually may streamline this a bit.

While I am committed to maintaining (code and resource use) minimalism, if there are ways to add really useful options with such a little impact on code size and resource use then I'm all for it.

Both of these options (bottom stack <-> right stack, and adjustible location of the split) will be adjustable while running and will be able to have key bindings to toggle or adjust them.

All it will really take is two variables. (Actually one with some bit-masks would do, but that would require more processing on each use). Expect to see these on git ~~by Monday~~. (edit: done)

Last edited by Trilby (2012-08-12 21:24:54)

2ManyDogs · 2012-08-11 21:47:59

That is awesome -- if I can bottom stack and adjust the size of the master area, I'll certainly use it somewhere in my machine collection...

Last edited by 2ManyDogs (2012-08-11 21:49:21)

Trilby · 2012-08-11 22:45:47

I feel like I just hit the Staples "Easy" button ... "damn, that was easy".

Optional bottom stacking, and adjustment of stack/master size is now on github.

It seems to be working here.

edit: typo. More edit:

In my next push I'll add the option to use commands "down" and "up" with the focus and move functions. This will not change any functionality, as this will already work with bottom stacking as is. But when using a bottom stack, a key binding that says focus("down") or focus("up") seems to make a lot more sense than "left" or "right".

For the lazy - or for those who really want to conserve every byte possible - the focus and move (and the new stackmode) functions only pay attention to the first character of the command string anyways. So focus("r"),focus("right"),and focus("rudolph the red nose raindeer") will all do the exact same thing. No point in using heafty string functions when a numerical comparison of arg[0] will do the job. The default bindings using full words is just a convenience for the user.

Last edited by Trilby (2012-08-11 22:54:37)

2ManyDogs · 2012-08-11 23:10:08

OK, this kind of works for me, maybe I'm doing something wrong. I set bstack to True in config.h and fact to 0.65. I rebuilt and started the WM. I opened a browser, then a terminal. The master size was 65% of the total, but the terminal opened to the right.

(edit) (I need to troubleshoot this some more -- I can't identify what works and when. Sometimes I get a bottom stack, sometimes not. It seems to depend on whether I close the master or the stack, but I'm not sure yet).

(edit2) (Open a browser, then a terminal. Browser moves to the right. Close the terminal, browser is max again, then open a terminal, browser goes down! Close terminal, browser goes to max, open a terminal, browser goes to the right again.)

I'm going to let you take a look at this now; maybe it's something obvious I'm doing wrong or something in the code.

Last edited by 2ManyDogs (2012-08-11 23:25:35)

Trilby · 2012-08-11 23:29:14

Thanks for the info. When I first read this, I was not able to replicate it. With the edits I might be able to narrow it down. If it is toggling back and forth with each window close, then I have a vague idea of what might be happening, though for the life of me I can't imagine how or why.

Is there any possibility ... oh wait. You didn't bind Mod-t to a terminal did you? I was going to ask if there is a possibility of a double binding. With the default config MOD-t "toggles" between the two modes (bottom or right). If this is also how a terminal is launched, that'd do it.

If not, I'll keep hunting.

edit: if this happens to be the problem, just comment/delete/change the MOD-t binding for toggling the layout (gasp, did I use the L word).
The default "b" "r" and "t" bindings are pretty dreadful, but they were the first to come to my mind to demonstrate the function - and they are easily changed.

Last edited by Trilby (2012-08-11 23:31:19)

2ManyDogs · 2012-08-11 23:31:00

son-of-a-b... of course I did, and I didn't even check (like I usually do) to see if it was bound to something else.

You sir, are an excellent troubleshooter. Back in a minute after a rebuild...

(edit) much better now. I feel stupid.

Is it the intended behavior for new windows to always open in the master area?

(edit2) Yes, I think urxvt would be a better choice (that's what I use )

(edit3) I usually change the mode switching keys to mod+shift+something because I don't use them much (that's what I did here)

Last edited by 2ManyDogs (2012-08-11 23:38:47)

Trilby · 2012-08-11 23:34:22

I just realized I should change the default TERM when I get around to it. I'm not sure I can stomache going with "xterm", but urxvt is much safer than assuming everyone is running urxvtd (daemon).

2ManyDogs wrote:

Is it the intended behavior for new windows to always open in the master area?

Currently yes. I'm open to modifying this though.

Edit: The currently intended behavior is to open the new window in the master region and shift the previous master client to the top of the stack. It seems only the first half of this is happening now. The previous master client is shifted to the stack region appropriately, but it is not put on the top of the stack. Expect this to be remedied with the next push. (edit: done)

Last edited by Trilby (2012-08-14 02:09:15)

2ManyDogs · 2012-08-12 00:31:43

Here's a screenshot with bottom stacking and the master area set to 0.65. I managed to fit a tiny conky (enough information for me) onto the status bar.

http://postimage.org/image/9i3lxi473/

Last edited by 2ManyDogs (2012-08-12 17:47:25)

aspidites · 2012-08-12 17:20:48

I suppose you could call it orientation rather than layout...

Left/Right/Up/Down is more intuitive, but if you wanted to reduce the number of aliases, you could probably just say Master/Stack (m/s) which is orientation/layout agnostic.

[crawls back in hole to lurk]

Trilby · 2012-08-12 21:23:44

Layout works. I have nothing against layouts - they're great. I just didn't want to make TinyTiler less tiny to implement them. As the bottom stack uses all the same code as right stacking, it was no problem to put in.

As for the directions (left/right/up/down), these would be what a user puts as an argument to the move function in config.h. master/stack would kinda' work, but a stack client can move left without moving to the master area. [ eg, windows A,B,C,D. A is in the master (left) region while B-D are stacked on the right. D can be moved left to make the window order A,B,D,C. You could say D moved towards the master, but not to it. ]

----

I just got rid of the known bug, and implemented the move-to-workspace function, so while certainly still very beta, ttwm should be fully functional. Now I'll be focusing on streamlining and improving stability for a bit. I'd love to hear what bugs turn up.

2ManyDogs · 2012-08-12 22:27:15

Just rebuilt, and I'm running it now. Move-to-workspace works well so far. I'll let you know if I encounter any bugs.

Left and right make sense to me, as those are the directions the indicators move on the status bar, even if I have the stack area below the master.

Mad_Hatter93 · 2012-08-12 22:41:35

So I cloned the git repository and compiled first, after tweaking the config.h a little bit, and compilation gave me no errors, in fact, no output at all, just a binary. I proceeded to install said binary, write a quick ttwm-specific .xinitrc, and see how it works. It didn't... so just for kicks, I tried to build from the AUR using packer, seeing what output that would give me. I got this lovely bit:

madhatterdor% packer -S ttwm-git
Password: 

Aur Targets    (1): ttwm-git

Proceed with installation? [Y/n] y
Edit ttwm-git PKGBUILD with $EDITOR? [Y/n] n
==> Determining latest git revision...
  -> Version found: 20120812
==> Making package: ttwm-git 20120812-1 (Sun Aug 12 17:29:55 CDT 2012)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving Sources...
==> Extracting Sources...
==> Removing existing pkg/ directory...
==> Starting build()...
==> Connecting to GIT server....
Already up-to-date.
==> The local files are updated.
==> GIT checkout done or server timeout
==> Starting make...
Cloning into '/tmp/packerbuild-0/ttwm-git/ttwm-git/src/ttwm-build'...
done.
In file included from ttwm.c:108:0:
config.h:51:2: error: initializer element is not constant
config.h:51:2: error: (near initialization for ‘keys[0].arg’)
config.h:52:2: error: initializer element is not constant
config.h:52:2: error: (near initialization for ‘keys[1].arg’)
config.h:53:2: error: initializer element is not constant
config.h:53:2: error: (near initialization for ‘keys[2].arg’)
config.h:54:2: error: initializer element is not constant
config.h:54:2: error: (near initialization for ‘keys[3].arg’)
config.h:55:2: error: initializer element is not constant
config.h:55:2: error: (near initialization for ‘keys[4].arg’)
config.h:56:2: error: initializer element is not constant
config.h:56:2: error: (near initialization for ‘keys[5].arg’)
config.h:57:2: error: initializer element is not constant
config.h:57:2: error: (near initialization for ‘keys[6].arg’)
ttwm.c: In function ‘main’:
ttwm.c:502:8: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
ttwm.c: In function ‘updatestatus’:
ttwm.c:395:9: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
ttwm.c:406:9: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
ttwm.c:415:9: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
ttwm.c:416:44: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
ttwm.c:417:44: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
make: *** [all] Error 1
==> ERROR: A failure occurred in build().
    Aborting...
The build failed.
madhatterdor%

This is my config.h:

/* See LICENSE file for copyright and license details. */

static const char font[] = "-*-terminus-medium-r-*-*-*-*-*-*-*-*-*-*";

#define NUMCOLORS	16
#define BARHEIGHT	13
#define FONTHEIGHT	11
#define WORKSPACES	5

#define CPU_FILE	"/proc/stat"
#define AUD_FILE	"/home/bill/.audio_volume"
#define BATT_NOW	"/sys/class/power_supply/BAT1/charge_now"
#define BATT_FULL	"/sys/class/power_supply/BAT1/charge_full"
#define BATT_STAT	"/sys/class/power_supply/BAT1/status"

static const char colors[NUMCOLORS][9] = {
	[Background]	=	"#101010",
	[Clock]			=	"#484862",
	[SpacesNorm]	=	"#484862",
	[SpacesActive]	=	"#6284FF",
	[SpacesSel]		=	"#FFDD0E",
	[SpacesUrg]		=	"#FF0000",  /* "Urgent" not yet implemented */
	[BarsNorm]		=	"#303030",
	[BarsFull]		=	"#122864",
	[BarsCharge]	=	"#308030",
	[BarsWarn]		=	"#997700",
	[BarsAlarm]		=	"#990000",
	[TitleNorm]		=	"#696969",
	[TitleSel]		=	"#4466FF",
	[StackNorm]		=	"#484862",
	[StackAct]		=	"#4466FF",
	[StackSel]		=	"#FFDD0E",
};

/* minimum percentage of screen that a window can take */
/*  and granularity in adjustment of master window size */
#define FACT_MIN	0.2
#define FACT_ADJUST	0.02
static uint8_t bstack	= False;	/* start with bottom stack? */
static float fact		= 0.50;		/* portion of screen for master window */

#define DMENU		"dmenu_run -fn \"-*-terminus2-medium-r-*-*-*-*-*-*-*-*-*-*\" -nb \"#101010\" -nf \"#484862\" -sb \"#080808\" -sf \"#FFDD0E\""
#define TERM		"urxvtc"
#define CMD(app)	app "&"

/* key definitions */
#define MODKEY Mod4Mask
static Key keys[] = {
	/* modifier			key			function	argument */
	/* launchers: */
	{ MODKEY,			XK_Return,	spawn,		CMD(TERM)		},
	{ MODKEY,			XK_p,		spawn,		CMD(DMENU)		},
	{ MODKEY,			XK_w,		spawn,		CMD("dwb")	},
	{ 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")},
	/* misc: (swap swaps master with top stack client) */
	{ MODKEY|ShiftMask,	XK_q,		quit,		NULL			},
	{ MODKEY,			XK_space,	swap,		NULL			},
	{ MODKEY,			XK_f,		fullscreen,	NULL			},
	{ Mod1Mask,			XK_F4,		killclient,	NULL			},
	/* switch focus / rearrange client windows: */
	{ MODKEY,			XK_j,		focus,		"left"			},
	{ MODKEY,			XK_k,		focus,		"right"			},
	{ MODKEY,			XK_h,		move,		"left"			},
	{ MODKEY,			XK_l,		move,		"right"			},
	{ MODKEY,			XK_Left,	focus,		"left"			},
	{ MODKEY,			XK_Right,	focus,		"right"			},
	{ MODKEY|ShiftMask,	XK_Left,	move,		"left"			},
	{ MODKEY|ShiftMask,	XK_Right,	move,		"right"			},
	/* increase or decrease master size.  */
	/* set bottom stack, right stack, or toggle between the two */
	{ MODKEY,			XK_i,		stackmode,	"increase"		},
	{ MODKEY,			XK_d,		stackmode,	"decrease"		},
	{ MODKEY,			XK_b,		stackmode,	"bottom"		},
	{ MODKEY,			XK_r,		stackmode,	"right"			},
	{ MODKEY,			XK_t,		stackmode,	"toggle"		},
	/* change workspaces: */
	{ MODKEY,			XK_1,		workspace,	"1"	},
	{ MODKEY,			XK_2,		workspace,	"2"	},
	{ MODKEY,			XK_3,		workspace,	"3"	},
	{ MODKEY,			XK_4,		workspace,	"4"	},
	{ MODKEY,			XK_5,		workspace,	"5"	},
	/* move client to workspace: !! Not implemented yet !! */
	{ MODKEY|ShiftMask,	XK_1,		putclient,	"1"	},
	{ MODKEY|ShiftMask,	XK_2,		putclient,	"2"	},
	{ MODKEY|ShiftMask,	XK_3,		putclient,	"3"	},
	{ MODKEY|ShiftMask,	XK_4,		putclient,	"4"	},
	{ MODKEY|ShiftMask,	XK_5,		putclient,	"5"	},
};

// vim: ts=4

I checked the Key keys=[] array, but it looks clean. Not sure what's happening here.

Trilby · 2012-08-12 23:03:28

Crap ... you're quite right Mad_Hatter, I'm getting this too. Something must be wrong from the last git push, standby.

I found one problem. I had a typo in closing a comment after the TERM definition when I changed it to urxvt. That caused the error for me, but your config.h doesn't have that. Are you sure the build is using that config.h? The typo-fix will be up on github momentarily.

That should be fixed now on both git and in AUR (as the PKGBUILD pulls from git). I just rebuilt from the AUR without error.

Last edited by Trilby (2012-08-12 23:08:18)

Doomcide · 2012-08-13 17:37:04

I just wanted to say thank you. The concept is great and intuitive and fits me really well, just have to squeeze in a conky somewhere, like 2MD

Trilby · 2012-08-13 19:06:02

Thanks.

For anyone who uses conky or other system monitors, if there is simple information you'd like to request incorporating into the monitor bars, let me know (and perhaps make a case).

I just did CPU, volume, and battery as they are the only bits of info I've found to be useful. I figure to justify a constant on screen display the information should be dynamic (which for me rules out disk space usage) and can be useful to respond to. I've considered a thermal monitor, that may happen at some point.

2ManyDogs · 2012-08-13 20:15:33

I don't think you need to add anything as long as there's a little room on the bar for a simple conky. You have to leave something for us to customize

I barely noticed the cpu bar (I'm on a desktop and don't care about volume). I didn't even know the bars were there at first.

Doomcide · 2012-08-13 20:49:39

2ManyDogs wrote:

I don't think you need to add anything as long as there's a little room on the bar for a simple conky. You have to leave something for us to customize

This.

Doomcide · 2012-08-14 08:09:37

I experienced two freezes of ttwm after using it for ~30m, yesterday. It didn't accept any keyboard input and the bar disappeared after a while. I'll try to find some time to troubleshoot this more, could also be a problem of my kernel (I compiled my first bootable kernel just last week (yay))

Trilby · 2012-08-14 11:33:38

Thanks, I've had that happen too. If it happens again, see if changing to another workspace then back has an effect. Also please keep track of whether there is any pattern in which title is visible/lost (eg the master or stack region). For me this has only happened right after closing a client, if that is the case for you too, keep track of where that client was (master or stack).

The trigger for unmanaging clients may be an oversimple kludge at the moment that can lead to some of these 'ghost client' effects. Hopefully shoring up that process will reduce/eliminate these.

I've also been trying to run different applications and had a couple crashes starting libreoffice. Unfortunately this hasn't replicated consistently here yet, and it may actually have been due a problem with a particular document I was trying to open. But whatever the cause, ttwm should cope with it a bit more gracefully than it did. (edit: while the cause of this is still unknown, ttwm will now handle this much more gracefully - no more crashing ... from this problem at least)

Last edited by Trilby (2012-10-30 11:39:51)

Doomcide · 2012-08-14 13:20:47

Trilby wrote:

Thanks, I've had that happen too. If it happens again, see if changing to another workspace then back has an effect. Also please keep track of whether there is any pattern in which title is visible/lost (eg the master or stack region). For me this has only happened right after closing a client, if that is the case for you too, keep track of where that client was (master or stack).

X doesn't accept any input anymore, all I can do is switch to tty and kill it. Furthermore the whole statusbar disappears, I'm not sure if I understood you correctly about the visible/lost title..?

Edit: It happened again on the debian-sid stock kernel and without closing a window.

Last edited by Doomcide (2012-08-14 14:35:47)

Arch Linux

#1 2012-08-11 18:27:48

Alopex: a tiling tagging tabbed window manager with fur

#2 2012-08-11 19:13:59

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

#3 2012-08-11 19:41:33

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

#4 2012-08-11 19:50:51

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

#5 2012-08-11 20:48:03

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

#6 2012-08-11 21:40:17

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

#7 2012-08-11 21:47:59

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

#8 2012-08-11 22:45:47

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

#9 2012-08-11 23:10:08

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

#10 2012-08-11 23:29:14

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

#11 2012-08-11 23:31:00

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

#12 2012-08-11 23:34:22

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

#13 2012-08-12 00:31:43

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

#14 2012-08-12 17:20:48

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

#15 2012-08-12 21:23:44

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

#16 2012-08-12 22:27:15

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

#17 2012-08-12 22:41:35

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

#18 2012-08-12 23:03:28

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

#19 2012-08-13 17:37:04

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

#20 2012-08-13 19:06:02

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

#21 2012-08-13 20:15:33

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

#22 2012-08-13 20:49:39

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

#23 2012-08-14 08:09:37

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

#24 2012-08-14 11:33:38

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

#25 2012-08-14 13:20:47

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

Board footer