You are not logged in.

#1 2012-09-01 13:08:32

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

xoat - x11 obstinate asymmetric tiler

X11 Obstinate Asymmetric Tiler

The urge to keep tweaking stuff on Arch can be distracting. I use goomwwm mostly and other WMs sometimes, but some days I need a way to automate self-control and concentrate on work...

Introducing xoat, the straitjacket of window managers.

  • Static tiling. Not dynamic; not manual; not floating; a single fixed asymmetric three-tile layout.

  • Place new windows by monitor, tile, or best-fit.

  • Mostly keyboard driven + click-to-focus.

  • EWMH subset to support docks and fullscreen toggle.

  • Works with simpleswitcher

  • Multi-head

  • config.h

github or PKGBUILD

--------------------------------
|                    |         |
|                    |         |
|                    |    2    |
|          1         |         |
|                    |---------|
|                    |         |
|                    |    3    |
--------------------------------

Why, you ask, Oh why give life to such an obstinate beast?

Using static tiling because:

  • Windows moving or resizing without user input is distracting.

  • Having a choice of layouts at run time is distracting.

  • Apps that remember size can handily be placed in the same tile.

  • Trivial to use tabbed apps, xembed, or tmux for complex stuff.

  • Straitjackets are surprisingly comfy... *twitch*

Using just three asymmetric tiles because apps fall into four classes:

  1. Large work-being-done apps.

  2. Medium monitoring-something apps.

  3. Small background-chat-music apps.

  4. Apps you should not use anyway wink

Trivia:

  • Pronounce it "zz-ote", like "goat".

  • ps_mem says ~350KiB usage.

  • ~1000 sloc.

Fine print: CAUTION. CUIDADO. ACHTUNG. Contains dangerously low distraction. Excessive use may cause productivity and zen-like calm. If symptoms persist please consult your normal WM.

Offline

#2 2012-09-01 17:16:31

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

Re: xoat - x11 obstinate asymmetric tiler

I like the ideology behind this. I want to report a few things I've noticed so far (I'm using the default config.h):

  • I'm not sure if it's the intended behavior or not, but removing fullscreen mode (i.e. mod4 + f on a window that is already fullscreen) moves the window to SPOT1 regardless of its previous position.

  • When a window in SPOT1 is made fullscreen, cycling windows with mod4 + ` does not cycle back to the fullscreen window, and mod4 + 1 must be pressed to return focus to it. This is not the case when a window in SPOT2 or SPOT3 is fullscreen.

  • When a window in SPOT2 or SPOT3 is made fullscreen, mod4 + tab cycles between the fullscreen window and the window in SPOT1. This obviously is not the case when a window in SPOT1 is fullscreen, but I'm not sure if that key combo should do something or if it intentionally does nothing.

  • Cycling windows with mod4 + tab reorders them. Hopefully my explanation will make sense. Say I have four instances of xterm open in SPOT1, called: A, S, D, and F, respectively (and in that order). Cycling with mod4 + `produces the expected result. Now, if xterm A has focus and mod4 + tab is pressed once, xterm S will have focus. Then, if mod4 + ` is pressed once, focus returns to xterm A. From this point, if mod4 + ` is used to cycle through all the windows, the order is observed to be A, D, F, S.

  • Lack of workspaces. Any plans to implement them, or would that be against the straitjacket philosophy? wink


I use linux and I dont understand nothing in this post.

Offline

#3 2012-09-02 01:12:34

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

Supplantr wrote:

I like the ideology behind this. I want to report a few things I've noticed so far (I'm using the default config.h):

  • I'm not sure if it's the intended behavior or not, but removing fullscreen mode (i.e. mod4 + f on a window that is already fullscreen) moves the window to SPOT1 regardless of its previous position.

Counts as distracting. Bug.

Supplantr wrote:
  • When a window in SPOT1 is made fullscreen, cycling windows with mod4 + ` does not cycle back to the fullscreen window, and mod4 + 1 must be pressed to return focus to it. This is not the case when a window in SPOT2 or SPOT3 is fullscreen.

  • When a window in SPOT2 or SPOT3 is made fullscreen, mod4 + tab cycles between the fullscreen window and the window in SPOT1. This obviously is not the case when a window in SPOT1 is fullscreen, but I'm not sure if that key combo should do something or if it intentionally does nothing.

I see what you mean. It's certainly not correct like this.

It does seem logical and useful to cycle between a fullscreen window and SPOT1. They both indicate large apps where work is being done. I'm not convinced cycling between fullscreen and SPOT2/3 is useful at all. One would have to remember which spot a FS window was in, or be risk being surprised by what it cycles with.

Supplantr wrote:
  • Cycling windows with mod4 + tab reorders them. Hopefully my explanation will make sense. Say I have four instances of xterm open in SPOT1, called: A, S, D, and F, respectively (and in that order). Cycling with mod4 + `produces the expected result. Now, if xterm A has focus and mod4 + tab is pressed once, xterm S will have focus. Then, if mod4 + ` is pressed once, focus returns to xterm A. From this point, if mod4 + ` is used to cycle through all the windows, the order is observed to be A, D, F, S.

That is the way it's meant to work, though you're welcome to try to convince me otherwise.

In config.h, ACTION_CYCLE, linked to ` (grave) pushes the top window to the bottom of the spot.  ACTION_OTHER, linked to Tab, swaps the top two windows in the spot.  Customize to taste.

Supplantr wrote:

Lack of workspaces. Any plans to implement them, or would that be against the straitjacket philosophy? wink

Nope, not going there smile  Would tags do?  Real simple; just a way to identify and group windows for raising?

Last edited by aerosuidae (2012-09-02 01:13:36)

Offline

#4 2012-09-02 05:25:11

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

Re: xoat - x11 obstinate asymmetric tiler

aerosuidae wrote:

I see what you mean. It's certainly not correct like this.

It does seem logical and useful to cycle between a fullscreen window and SPOT1. They both indicate large apps where work is being done. I'm not convinced cycling between fullscreen and SPOT2/3 is useful at all. One would have to remember which spot a FS window was in, or be risk being surprised by what it cycles with.

I agree. Regarding the (possibly) incorrect behavior: upon further investigation I've observed that when a window is fullscreen and there are windows in SPOT2 and/or SPOT3 but not SPOT1, calling ACTION_CYCLE makes the other windows visible but continued cycling doesn't return focus to the fullscreen window. This doesn't happen if there is a window in SPOT1.

aerosuidae wrote:

That is the way it's meant to work, though you're welcome to try to convince me otherwise.

In config.h, ACTION_CYCLE, linked to ` (grave) pushes the top window to the bottom of the spot.  ACTION_OTHER, linked to Tab, swaps the top two windows in the spot.  Customize to taste.

Makes sense. Thanks for the clarification.

aerosuidae wrote:

Nope, not going there :)  Would tags do?  Real simple; just a way to identify and group windows for raising?

That sounds like a good idea. Also, what about automatic positioning of new windows in specified SPOTs?

This may be a bug. Here are steps to reproduce:

  1. Populate SPOT1 with a single window and the other two SPOTs with any number of windows.

  2. Make the window in SPOT1 fullscreen.

  3. Call ACTION_CYCLE once. (Further calls won't do anything anyway.)

  4. Press mod4 + f again.

  5. Make the window in SPOT1 fullscreen and observe that the windows in the other two SPOTs appear on top of the fullscreen window.

And another:

  1. Populate SPOT1 with more than one window and the other two SPOTs with an arbitrary number of windows.

  2. Make one of the windows in SPOT1 fullscreen.

  3. Call ACTION_CYCLE once. The window in SPOT1 should be in focus and the windows in the other spots should be visible.

  4. Make the now-focused window in SPOT1 fullscreen.

  5. Call ACTION_CYCLE multiple times. Cycling only occurs between the two fullscreen windows. It seems that this only happens if the two fullscreen windows originated from SPOT1.


I use linux and I dont understand nothing in this post.

Offline

#5 2012-09-02 06:27:46

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

Windows are now assumed to be SPOT1 while full screen but will toggle back to their original spot; they also get raised on toggle. I think this fixes the bugs you noted.

Supplantr wrote:

What about automatic positioning of new windows in specified SPOTs?

Care to describe this a bit more?  config.h has a few examples for defining a SPOT_START setting, but perhaps you mean something else?

Offline

#6 2012-09-02 14:01:07

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

Re: xoat - x11 obstinate asymmetric tiler

aerosuidae wrote:

Care to describe this a bit more?  config.h has a few examples for defining a SPOT_START setting, but perhaps you mean something else?

I meant something along the lines of starting a new window in a given SPOT based on WM_CLASS, e.g. "chromium" start in SPOT1, "urxvt" start in SPOT3, etc. Essentially paralleling how other tiling WMs can start apps on specified workspaces. Although, I might be misunderstanding how SPOT_SMART operates.

I don't have a second monitor so I'm not exactly sure how xoat works with respect to multi-head, but perhaps the ability to denote which monitor to start an app would also be useful.

There is a visible gap between terminal emulators in SPOT2 and SPOT3 as well as a gap between the top and bottom of the screen, respectively. Is there any way to avoid this?


I use linux and I dont understand nothing in this post.

Offline

#7 2012-09-02 15:04:52

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

Supplantr wrote:

I meant something along the lines of starting a new window in a given SPOT based on WM_CLASS, e.g. "chromium" start in SPOT1, "urxvt" start in SPOT3, etc. Essentially paralleling how other tiling WMs can start apps on specified workspaces. Although, I might be misunderstanding how SPOT_SMART operates.

Ah, like placement rules.

SPOT_SMART places a window in the spot of best fit. If an app remembers it's size it should show up in the same place each time. If apps support -geometry that should work too as a way to place them.

I'm not going to add rules just yet. Sounds dangerously liberating smile

Supplantr wrote:

There is a visible gap between terminal emulators in SPOT2 and SPOT3 as well as a gap between the top and bottom of the screen, respectively. Is there any way to avoid this?

Use another terminal app.

Most terminals draw windows based on their text size (x cols, y rows) so they won't fill a tile completely. We could force them to do it, but many then do silly stuff like freeze up or draw garbage in the gaps.

I don't know of any lightweight terminal that does not leave gaps. One heavyweight that fills tiles nicely is konsole.

In other news, I added simple tags.

Offline

#8 2012-09-02 20:09:25

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

Re: xoat - x11 obstinate asymmetric tiler

aerosuidae wrote:

In other news, I added simple tags.

It seems to be working pretty well. I was a bit surprised to see that you "hard-coded" three tags rather than allowing windows to be dynamically tagged on creation.

For some reason I was under the impression that ACTION_CYCLE is supposed to cycle through all windows. Now that I'm thinking clearly, the way it behaves seems much more sane.

It appears that fullscreen windows are moved to SPOT1, then returned to their previous SPOT upon removing fullscreen. It might make sense to allow fullscreen windows to be cycled to from any SPOT, that way a window in SPOT1 doesn't need to have focus for cycling to return focus to the fullscreen window.


I use linux and I dont understand nothing in this post.

Offline

#9 2012-09-03 01:27:09

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

Supplantr wrote:

I was a bit surprised to see that you "hard-coded" three tags rather than allowing windows to be dynamically tagged on creation.

xoat doesn't do dynamic wink

Supplantr wrote:

It might make sense to allow fullscreen windows to be cycled to from any SPOT, that way a window in SPOT1 doesn't need to have focus for cycling to return focus to the fullscreen window.

I tried this but found it annoying as the full screen window kept floating to the top of the stack in all spots. One workaround could be to have full screen windows drop back to SPOT1 size when they lose focus. Another is to try out the multi-head support; use one monitor for tiling and one for full screen.

But... it's all starting to feel too complicated for xoat.  I think treat full screen as something to toggle on when the window is in use and off when not.

Offline

#10 2012-09-03 15:55:09

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

Re: xoat - x11 obstinate asymmetric tiler

aerosuidae wrote:

But... it's all starting to feel too complicated for xoat.  I think treat full screen as something to toggle on when the window is in use and off when not.

You're right. Keep it simple.

So, up until now I've been testing xoat with Xephyr. Now that I'm actually using it, I have yet another thing to say about fullscreen! I'm not sure if there's a technical way to put it, but making a window fullscreen works on the application itself rather than just the window. Such as, chromium makes itself fullscreen (i.e. "You have gone full screen. Exit full screen (F11)") rather than the window being maximized to fill the screen. This means tabs aren't visible when in fullscreen mode. Shouldn't the window manager just maximize the window, then allow the application to handle making itself "truly" fullscreen? If this is a dumb question because I'm not understanding something fundamental, feel free to ignore it. :P


I use linux and I dont understand nothing in this post.

Offline

#11 2012-09-04 00:52:03

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

Windows are made full screen by setting _NET_WM_STATE_FULLSCREEN and then maximizing them. How applications handle that transition is not controlled by xoat. This is pretty much as per EWMH standard, though, I don't mind breaking that compatibility if we can think of a better way to do it.

Looks like chromium is detecting the _NET_WM_STATE change and displaying the "You have..." message. No idea why it hides its tab bar, though fwiw Ctrl+Tab still works to switch tabs. Possibly some setting or extension would show it.

Offline

#12 2012-09-08 19:13:43

netfun81
Member
Registered: 2008-07-20
Posts: 32

Re: xoat - x11 obstinate asymmetric tiler

Nice Window manager, I like the minimalism.  Been using it for a couple days.  There is a bug at least on my system that will cause the window manager to exit if the F1-F3 keys are pressed repeatedly.  I solved this by changing to "Action_Command" even though this launches a new occurance it is better than crashing.

{ .mod = AnyModifier, .key = XK_F1, .act = ACTION_COMMAND, .data = "xterm"    },

Let me know if you are able to duplicate and fix.  I would like to use it as you have envisioned. 

p.s. Two small feature requests  1.  A "Quit" option that can be assigned to a hotkey.   2.  Option for "focus follows mouse" and "autoraise"   

Thanks, I like your Goomwwm also and Musca.

Last edited by netfun81 (2012-09-08 19:24:25)

Offline

#13 2012-09-09 21:01:57

niski
Member
Registered: 2012-09-09
Posts: 9

Re: xoat - x11 obstinate asymmetric tiler

netfun81 wrote:

1.  A "Quit" option that can be assigned to a hotkey.

You can assign any hotkey to 'killall xoat'.

Offline

#14 2012-09-09 21:34:00

Doomcide
Member
Registered: 2011-08-22
Posts: 221

Re: xoat - x11 obstinate asymmetric tiler

niski wrote:
netfun81 wrote:

1.  A "Quit" option that can be assigned to a hotkey.

You can assign any hotkey to 'killall xoat'.

This gets difficult if you have more than 1 X-Server running xoat at the same time.

Offline

#15 2012-09-10 03:16:17

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

The xoat binary can be used in client mode to control an already-running instance:

xoat restart
xoat exit

Set $DISPLAY if running multiple instances.

Should be ok to add the key binding options too. Will check out the crash; thanks for reporting it!

Edit: @netfun81, sorry, I forgot your second request...

I personally cannot stand focus-follows-mouse, but I know some folks love it so I'm willing to consider adding it. But, how to deal with the following scenario?

  1. Mouse over window.

  2. Move window to another tile by keyboard.

  3. Mouse now potentially over a different window.

  4. Where should the focus go?

What use case do you have in mind for autoraise in a pure tiling WM?

Last edited by aerosuidae (2012-09-10 06:15:23)

Offline

#16 2012-09-10 16:36:50

netfun81
Member
Registered: 2008-07-20
Posts: 32

Re: xoat - x11 obstinate asymmetric tiler

aerosuidae thanks for reply!   After thinking about the focus for a minute, what I really want is an option to make new windows focused.   Currently, at times I start a new program and forget to click on it before moving it and end up moving another window with focus.   I would be happy with that option and wouldnt need focus-follows-mouse.  Was thinking autoraise was needed for focus nevermind my ignorance.

EDIT:  Just to be clear, I have all new windows starting into the master area.  However focus will stay at the last tile area.  I tend to move a new window right after launching it.

Last edited by netfun81 (2012-09-10 16:44:44)

Offline

#17 2012-09-11 00:51:57

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

@netfun81, that makes sense. Thanks for the extra detail.

I've added a FOCUS_START definition to config.h. See in-line comment there for usage.

Edit: re. the F1/F2/F3 crash. I can't reproduce it yet. Are you seeing a hard crash, like a segfault, or an X protocol error (which would print info on stderr)? If possible, build the xoat-debug binary and run it from gdb or valgrind to get a stack trace.

Last edited by aerosuidae (2012-09-11 01:10:35)

Offline

#18 2012-09-11 17:24:11

netfun81
Member
Registered: 2008-07-20
Posts: 32

Re: xoat - x11 obstinate asymmetric tiler

Thanks aerosuidae the focus option works perfectly!   concerning the crash, I tried compiling with the default config.h and I could not reproduce the crash.  I then edited the config.h with the following added lines:

{ .mod = AnyModifier, .key = XK_F1, .act = ACTION_FIND_OR_START, .data = "urxvt"    },
    { .mod = AnyModifier, .key = XK_F2, .act = ACTION_FIND_OR_START, .data = "iceweasel" },
    { .mod = AnyModifier, .key = XK_F3, .act = ACTION_FIND_OR_START, .data = "pcmanfm"  },
        { .mod = AnyModifier, .key = XK_F4, .act = ACTION_FIND_OR_START, .data = "alsamixergui"  },
        { .mod = AnyModifier, .key = XK_F5, .act = ACTION_FIND_OR_START, .data = "gksu synaptic"  },

The crash then came back after multiple presses.  It appears to be a segfault as no errors are displayed just an exit from X.  Also as a note, I am on Debian sid instead of arch if that makes any difference.   

EDIT:  I think I may have found the issue.  When pcmanfm is running it assigns F4 to open a terminal to current window.   When i assign F4 to something else with xoat the conflict is created.   I will test more by assigning modifier Mod4 with F keys.

EDIT2:  Assigned Mod4 with function keys and crash still occurs with the F4 and F5 added.   Will do some more testing.

Last edited by netfun81 (2012-09-11 18:06:01)

Offline

#19 2012-09-13 06:02:27

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

@netfun81, a gdb back trace would help...

Not having that, I've committed some tweaks to make the ACTION_FIND_OR_START handler generally more robust. Give it a try.

Also, a small point possibly unrelated to the crash: The .data field for ACTION_FIND_OR_START is a text string matched against windows' WM_CLASS. For many apps this nicely doubles as a command to start them. Is "gksu synaptic" a real WM_CLASS?

Offline

#20 2012-09-15 04:56:02

netfun81
Member
Registered: 2008-07-20
Posts: 32

Re: xoat - x11 obstinate asymmetric tiler

thanks aerosuidae!  i downloaded the latest build and fixed F4 and F5.   F4 Alsamixergui didnt have a wm_class according to xprop and F5 was not a good wm_class, even though pressing them launched the correct program.   I havent had a crash with the new build and those changes.

Last edited by netfun81 (2012-09-16 06:02:43)

Offline

#21 2012-09-25 01:21:23

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

Update:

  • Added a directional move action which works more intuitively with the arrow keys, regardless of whether the layout alignment is flipped.

  • Added real simple title bars that show all windows in a tile. Kind of like tabs in some other tiling WMs, but much cruder and only triggered by key bindings.

  • Better _NET_WM_STRUT* support on multi-head.

config.h has has some minor changes and additions, so it will need merging or just start with a clean copy smile  Eg, the ACTION* constants have been replace with action* functions, because the former added an unnecessary layer.

Code has ballooned out to around 1200 sloc. Bit unhappy with that, but have some ideas for beating it back into submission...

Last edited by aerosuidae (2012-09-25 01:22:03)

Offline

#22 2012-11-13 15:44:44

niski
Member
Registered: 2012-09-09
Posts: 9

Re: xoat - x11 obstinate asymmetric tiler

Do you use any tray application with xoat? Or know of any app which works with it?

I have tried stalonetray but ended up with two screens being almost completely covered with the tray - I haven't configured it yet, though.
I'd be happy having any tray app put in smallest tile, right now one of my wine apps creates separate wine tray (with gray rectangle as background) but of course it doesn't take into account any native apps' icons.

Offline

#23 2012-11-13 19:39:12

Pranavg1890
Member
From: Nagpur,India
Registered: 2012-09-07
Posts: 114

Re: xoat - x11 obstinate asymmetric tiler

Hi , can you give us a symmetric version of the above tiler?


Using Openbox + Tint2 + Idesk

Offline

#24 2012-11-13 20:03:48

flipper T
Member
Registered: 2012-09-14
Posts: 419

Re: xoat - x11 obstinate asymmetric tiler

Hi, any chance of wobbly windows ?



smile


If I'm curt with you it's because time is a factor. I think fast, I talk fast and I need you guys to act fast if you wanna get out of this. So, pretty please... with sugar on top. Clean the [censored] car. -The Wolf

Offline

#25 2012-11-13 22:21:06

aerosuidae
Member
Registered: 2009-03-10
Posts: 248

Re: xoat - x11 obstinate asymmetric tiler

niski wrote:

Do you use any tray application with xoat? Or know of any app which works with it?

I use lxpanel.

Pranavg1980 wrote:

Hi , can you give us a symmetric version of the above tiler?

You can configure the tile proportions in config.h.

flipper T wrote:

Hi, any chance of wobbly windows ?

rofl

Last edited by aerosuidae (2012-11-13 22:21:54)

Offline

Board footer

Powered by FluxBB