xaizek / euclid-wm (License: BSD 3-Clause) (since 2018-12-07)
A minimalist, tiling window manager for X11 that seeks to allow easy management of numerous windows entirely from the keyboard.
Clone URLs: https://code.reversed.top/user/xaizek/euclid-wm ssh://rocketgit@code.reversed.top/user/xaizek/euclid-wm
fix-a-crash master multihead wiki
Commit efd64f84fcc9aacbafb3bff18d26eb622859ec7a

Migrating wiki contents from Google Code
Author: Google Code Exporter
Author date (UTC): 2015-09-06 14:10
Committer name: Google Code Exporter
Committer date (UTC): 2015-09-06 14:10
Parent(s):
Signing key:
Tree: e623eca781ae226936d7e8d683746a69bbd46176
File Lines added Lines deleted
ProjectHome.md 48 0
QnA.md 46 0
dev_install.md 71 0
feedback_guidlines.md 46 0
scrots.md 25 0
stable_install.md 35 0
usagetutorial.md 184 0
File ProjectHome.md added (mode: 100644) (index 0000000..4cc7fed)
1 **STATUS:**
2 The current stable release is 0.4.2 and can be downloaded [here](https://code.google.com/p/euclid-wm/downloads/list).
3
4 If you need help with the tarball see [the instructions](http://code.google.com/p/euclid-wm/wiki/stable_install).
5
6 If you are interested in helping with development, check out [our development instructions](https://code.google.com/p/euclid-wm/wiki/dev_install)
7
8 Also please note that euclid is moving to [a new home](http://euclid-wm.sourceforge.net/index.php), please consider updating any links you have.
9
10 The following is for purely historical interest.
11
12 ---
13
14
15 euclid-wm is a minimalist, tiling window manager for X11. It is designed to allow quick and easy management of numerous windows entirely from easy-to-learn, vim-like key-bindings.
16
17 Although there is a [plethora](http://wiki.archlinux.org/index.php/Comparison_of_Tiling_Window_Managers) of other tiling WMs, euclid-wm seeks to do two things in particular:
18
19 * balance the ease of use common among automatic-layout tiling window manager with the flexibility of manual layout WMs.
20
21 * create a useful way to handle minimized applications.
22
23 Some features:
24 * small,
25 ```
26 $ ps -o comm,vsize,rss,trs,drs,cputime -C euclid-wm
27 COMMAND VSZ RSS TRS DRS TIME
28 euclid-wm 3184 1096 25 3158 00:00:00
29
30 ```
31 (as of 0.1.0).
32 * completely keyboard controlled, no need to reach for the mouse . . . ever.
33 * a per view/workspace stack that manages minimized/unmapped windows.
34 * handles fullscreen for most apps, (at the moment flash is an exception, but there is an easy workaround)
35 * simple (non-XML) configuration file
36 * easy manual layout (position and resize windows with vim-style keybindings) that enforces no-gap tiling (windows are automatically resized to fill gaps or empty cells)
37 * no floating layer, (this is a feature)
38 * plays nice with dzen or similar external apps that set overrideredirect or write directly to root (see the config file for more)
39 * on the fly reloading of settings (keeps your layout intact)
40
41 For a bit more, check out the wiki, look at [some screenshots](http://code.google.com/p/euclid-wm/wiki/scrots) or just checkout the code and see for yourself.
42
43 If you are are using euclid please consider joining [the mailing list](http://groups.google.com/group/euclid-wm) to keep up on this project (It isn't high volume, I promise.) You can also subscribe to the [feed](http://code.google.com/feeds/p/euclid-wm/updates/basic).
44
45 The development version is available via svn (see the [instructions](http://code.google.com/p/euclid-wm/wiki/dev_install)) and the latest stable is available as a tarball. For Arch users it is also available from AUR. (A big thanks to BKLive for maintaining it).
46
47
48 euclid-wm is **not** related to any other project named "euclid" that is not an X11 window manager.
File QnA.md added (mode: 100644) (index 0000000..fbb2044)
1 Questions and Answers
2
3
4
5 # Why a tiling window manager? #
6 There are two basic arguments in support of tiling window managers:
7
8 * They make sense
9 * They are more keyboard friendly
10
11 The fundamental idea behind a tiling window manager (or at least behind most tiling window managers) is that if the user wants a window displayed, it should be displayed. This means it should not be obscured by other windows, and that it should be given as much screen space as possible. This seems to make sense; After all, why would a person want to see a window, but only partly blocked by another?
12
13 The guiding principle then is that if a user attempts to display a window, the window manager should display the window, and it should display it giving it as much of the screen as is available. If the space available is larger than the window needs, the the program can decide how to use (or ignore) the extra space (or the user can reallocate space himself, giving it to a window that is more important or just needs more space). If the window gets less space than it wants, again, it can decide what to display and what to drop, or the user can choose to free up space to give it (by resizing it, or by minimizing or moving unneeded windows).
14
15 Further it seems obvious that the current floating window model is fundamentally broken: the model where the window manager simply vomits the windows onto the screen and leaves the user to sort through the mess. This model gained popularity, it appears, because in the 80's it seems hip (much as some current eye candy WMs are popular, not because they are more usable, but because they seem futuristic and cool). A computer desktops is not like a real desktop, windows are not pieces of paper that we pick up and move around. This is a general problem with the WIMP interface: Modeling a computer interface on physical objects (so you can point to them, drag them around, etc.) might be good for initial learning, but it is generally far from optimal efficiency. I wish that my desk would hide papers that I'm not using, and organize the ones I am to be non-overlapping, without my having to pick them up, sort through them, and meticulously arrange them. Of course this model quickly became the de facto standard, and thus it is what most people today are comfortable with. But to a person accustomed to a decent tiling window manager, going back to a floating window manager is painful, all the awkward window moving and resizing is an exercise in frustration and an utter waste of time.
16
17 To see how this model is fundamentally broken consider how it has become popular, sometimes expected, for individual programs to implement their own screen multiplexing mechanisms (most popularly tabs, but also the horribly unusable sub-window paradigm). The fact that today every major web browser (and many other programs beside) come with a tabbing system is evidence of the fact that the old model of window management is incapable of handling large numbers of windows in a usable way. (Some other favorite bad ideas of mine or compositing--the point of a window is to see them, why would I want my windows to blur together?--and the desktop--let's put all the most important things in a place that will be the first to be inaccessible when the interface is used!).
18
19 The second benefit of tiling window managers is that they lend themselves nicely to keyboard control. Again, most people are used to manipulating windows with some sort of pointer and don't notice the awkwardness (for example of trying to get the pointer right over the border to resize a window), but for a competent user, keyboard shortcuts are (able to be) much faster. (If you doubt that the keyboard is a faster way of interacting with a computer, then euclid-wm probably isn't for you.)
20
21 # Why _another_ tiling window manager? #
22 The window managers I was aware of all seemed to lack something. The specific things I wanted were easy, intuitive dynamic layout, and a graceful way to handle minimized windows. scrotwm was a huge inspiration. It's interface was dead simple to learn, and very intuitive (it got me hooked on tiling window managers). But it was a bit limited in its layout, and it's stack didn't unmap windows; Windows in the stack were mapped, they were just small: thus windows in the stack (a) always took up space and (b) became difficult to identify as the number of windows in the stack grew.
23
24 wmii also had a lot of things that felt right: I really liked the minimize (stacked layout) idea, but I didn't like the fact that the stack was per cell as opposed to per desktop.
25
26 With i3 I liked the ability to move windows with hjkl, and to use these keys to make new columns and rows. But I didn't like the table paradigm, which would leave empty cells, unless the user explicitly told the window to span the cells.
27
28 So I decided to take what I liked and build euclid-wm.
29
30 # Why Xlib and not XCB? #
31 The big advantages of XCB are that it reduces latency (by allowing asynchronous communication with the X server) and that it allows a more low-level access to the X protocol.
32
33 The disadvantages of XCB (compared to Xlib) are that it is new (far less documentation) and that (because it is less abstracted from the protocol) it requires more work.
34
35 The fact that it is new means not only is there much less documentation, but that there are fewer projects to look at when you need an example.
36
37 As to the advantages of XCB. I didn't need low-level access to the X protocol. I also wasn't concerned with the latency. Xlib has been fast enough--even over network connections on 80's era hardware--for a long time. Shaving 90% off a negligibly fast operation doesn't give much real benefit. (This isn't to say that there aren't modern applications that might benefit from such a speed-up, but a minimalist WM like euclid doesn't seem to be one of them.)
38
39 I'm not sorry for this decision: euclid, has no issues at all with not being responsive, and trying to implement it in XCB might well have kept me from finishing it.
40
41 # Why no multihead support? #
42 I don't have a multihead setup. Thus I lack both the motivation and means to implement such support.
43 If you want multiscreen support you have three options:
44 1. Donate a multihead setup to me.
45 1. Write a (good) patch yourself and submit it.
46 1. Offer to work with me to develop a good patch (I have a pretty good idea of what would need to be done to get it working).
File dev_install.md added (mode: 100644) (index 0000000..4b9ad1b)
1 # Basic Testdrive #
2
3 * First get the latest source:
4
5 ```
6 svn checkout http://euclid-wm.googlecode.com/svn/trunk/ euclid-wm-read-only
7 ```
8
9 * cd into the trunk directory
10
11 Note: you will need to have the Xlib and Xinerama headers installed prior to compiling. On Debian you can get them by installing libx11-dev and libxinerama-dev.
12
13 * Compile:
14 ```
15 make clean
16 make
17 ```
18
19 * Install:
20 ```
21 su
22 make install
23 suspend
24
25 ```
26
27 * Read the man page **before** trying it out:
28 ```
29 man euclid-wm
30 ```
31
32 > Note: By default euclid-wm uses xterm and dmenu as the terminal and menu respectively; running euclid-wm without having either installed them or reconfigured euclid-wm to use alternatives gives a substandard user experience.
33
34 * Give it a go: Log out and log in using the euclid session.
35
36 # Debugging #
37 Debugging a window manager poses its own set of problems, here is the best way I've found to do it:
38
39 * Checkout as above
40
41 * Compile with:
42 ```
43 cc -O0 -g -lX11 -lXinerama -oeuclid-wm euclid-wm.c
44 ```
45
46 * Start a new virtual terminal (if you are doing this several times, starting the doing this from within the directory where you compiled will save you some typing when you in the next step):
47 ```
48 su
49 xinit -- :1 vt12
50 ```
51
52 * You should be in a new vt with a single xterm. In the xterm, cd to the directory where you compiled. Optionally switch from root. Then
53 ```
54 screen gdb euclid-wm
55 ```
56
57 * Start euclid, within gdm:
58 ```
59 r
60 ```
61
62 * Then `<ctrl> + a, d` to detach screen
63
64 * Switch back to the original vt `<ctrl> + <alt> + <F7>`
65
66 * Attach to the screen session:
67 ```
68 screen -r
69 ```
70
71 * Go back to vt12 and do what you want to do, `<ctrl + <alt> + <F12>`
File feedback_guidlines.md added (mode: 100644) (index 0000000..15089f0)
1 #on submiting feature requests, bug reports, and patches
2
3
4
5 # Feature requests, bug reports, and patches #
6 I deeply value the feedback that I've gotten so far. It has been invaluable to me in finding problems and mapping out my plans for euclid. So a heartfelt "thank you" to all the testers and users who have taken time to help me improve euclid.
7
8 But here are some general points I'd ask you to consider before giving feedback.
9
10 The following are not directed to any individual: Although I use the 2nd person liberally, **do not take these comments personally**.
11
12 ## Feature requests ##
13 Here are some general things to consider before submitting a feature request:
14
15 First off, euclid-wm is meant to be minimalist; I refuse to succumb to feature creep. If a feature is genuinely going to save a lot of time, or make euclid capable of handling something it can't otherwise handle, I'm open to implementing it, but before I add a feature I want to know that there is a real need for it. This the first reason that euclid doesn't have tagging: tagging seems to me like something that is very rarely useful (although it is cool), and the benefit I see seems to me to be far outweighed by the two following considerations.
16
17 Second, I want euclid's code to be maintainable. In general I want to keep the code as comprehensible as possible without sacrificing important functions.
18
19 Third, and most importantly, I do not want to multiply keybindings without need. I want euclid's behavior well-defined, predictable, and easy to memorize. Adding 8 new keybindings to accomodate some rarely used feature is not desirable. This is the primary reason euclid doesn't have a floating layer (but the above considerations, and some others play a real role).
20
21 As to my estimation of whether these considerations ballance out, I'm open to hearing arguements in support of features I don't think are worth the cost. I'm perfectly willing to admit that I might have missed something, or that my vision of how euclid works out in real life isn't perfect.
22
23 So if you are approaching me with a feature request be ready to explain in detail why the feature is necessary. If I don't think a feature fits into euclid, I'll say so, and I'll probably list some reasons. Don't take it personally. When you asked for the feature you forced me to make a decision (whether to implement it or not), in explaining my reason I'm justifying my decision rather than just saying "no" without an explanation.
24
25 And please describe the feature in detail and how the desired feature differs from current behavior. Really spell it out.
26
27 Also, I'm much more receptive to feature requests that are phrased as "I'd really like to be able to . . ." or "I think it could be useful to be able to . . ." or "I'd switch to euclid full-time if I could . . ." or "do you have plans to implement . . ." as oposed to "euclid needs to . . ." or what's worse, "you need to . . . " Does it? Do I? (Admittedly sometimes these are absolutely right; Sometimes I have made a mistake or just been lazy, but that is generally more applicable to bug reports than feature requests.)
28
29 Of course I'd really rather hear "I'd like to implement x. Where should I start?"
30
31 ## Bug reports ##
32
33 I really appreciate bug reports: I want euclid to be stable and predictable. But please be as descriptive as possible. General "euclid doesn't act right when I <do some common activity>" doesn't do much to help me. I need as many details as you can give before I can even start tacking down--let alone fixing--the issue. This means steps (from a clean start) to reproduce the bahavior if it is possible.
34
35 And the bug may have already been corrected. So either update to the newest rev, or try to give me an idea of which revision you have installed (even if that is just telling me about what day you installed it and how you installed it, the newest versions of euclid write a VERSION file in /usr/share/euclid-wm).
36
37 If you are reporting a bug, please consider filing it under the "issues" tab. This draws visibility to it for the sake of other curent users or potential users who might experience the same issue. I haven't always been good about this myself, but I would like to get it so that "issues" really is a complete list of all significant known issues allong with any information on work-arounds, debugging the problems, and fixing them. (This isn't really a big deal, just a preference.) Also when reporting issues, please enter separate issues for seperate bugs. This makes everything a lot easier.
38
39 Sending a precise description of the bug is the most important part of reporting a bug, _even if you think you have a fix for it_.
40
41 ## Patches ##
42 Writing a patch is by far the fastest way to get something implemented in euclid (if you want something done **now**, you often have to do it yourself). Contrary to some people's opinion, I do have a life, and my list of priorities for euclid may not be the same as yours (so your must-have feature may be in the at-some-indefinite-point-in-the-future category on my list).
43
44 If you are thinking about writing a patch, for the sake of your own time it is probably wise to contact me before you have too much invested in it. This is because (a) I might not want the patch (b) I know the code pretty well, and could probably save you some time.
45
46 If you don't like my attitude, my plans for the project, or in general the direction I'm taking euclid: I'm sorry. But for your consolation the code is BSD licensed and available through anonymous svn, so you are free to fork at any time. This of course is not to say that I want it forked, but if it does get to the point where you say to yourself "euclid is perfect for me except for x, y, z, which I cannot live without and he has made it completely clear that he will never implement any of these features" then I'm not going to stand in the way of your having your perfect wm. That's the beauty of OSS.
File scrots.md added (mode: 100644) (index 0000000..18f5a2e)
1 There really isn't much to see here: euclid's minimalism goes beyond low system requirements, it also avoids taking up screen space. But just because people seem to love screenshots, here is euclid in action:
2 <p>
3 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-scrot3.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-scrot3.png' height='160' width='256"' /> </a>
4
5 A couple of xterms and chrome, dzen at the top, with a visible stack.<br>
6 </p>
7
8 <p>
9 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-scrot4.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-scrot4.png' height='160' width='256"' /> </a>
10
11 A few xterms, w/dzen, and a visible stack.<br>
12 </p>
13
14 <p>
15 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-scrot1.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-scrot1.png' height='160' width='256"' /> </a>
16
17
18 More xterms and chrome. No stack or dzen.<br>
19 </p>
20
21 <p>
22 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-scrot5.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-scrot5.png' height='160' width='256"' /> </a>
23
24 xterms, dzen, empty stack.<br>
25 </p>
File stable_install.md added (mode: 100644) (index 0000000..cf68931)
1 # Installation #
2
3 Please ignore the naive automatic highlighting.
4
5
6 ```
7 :~$ wget http://euclid-wm.googlecode.com/files/euclid-wm-0.1.1.tar.gz
8 --2010-07-23 16:17:36-- http://euclid-wm.googlecode.com/files/euclid-wm-0.1.1.tar.gz
9 Resolving euclid-wm.googlecode.com... 72.14.204.82
10 Connecting to euclid-wm.googlecode.com|72.14.204.82|:80... connected.
11 HTTP request sent, awaiting response... 200 OK
12 Length: 19832 (19K) [application/x-gzip]
13 Saving to: “euclid-wm-0.1.1.tar.gz”
14
15 100%[===================================================>] 19,832 54.7K/s in 0.4s
16
17 2010-07-23 16:17:42 (54.7 KB/s) - “euclid-wm-0.1.1.tar.gz” saved [19832/19832]
18
19 :~$ tar -xzf euclid-wm-0.1.1.tar.gz
20 :~$ cd euclid-wm-0.1.1/
21 :~/euclid-wm-0.1.1$ make
22 cc -pedantic -Wall -lX11 -O2 -std=c99 euclid-wm.c -o euclid-wm
23 :~/euclid-wm-0.1.1$ su
24 Password:
25 :/home/wmdiem/euclid-wm-0.1.1# make install
26 :/home/wmdiem/euclid-wm-0.1.1# suspend
27 [1]+ Stopped su
28 :~/development/src/euclid-wm-0.1.1$ man euclid-wm
29 ```
30
31 If you use a display manger euclid-wm should now be in its list of sessions.
32 If you use xinitrc, you should `exec start-euclid`.
33
34
35 NOTE: you should either make sure you have dmenu and xterm installed prior to running euclid-wm, or you should edit the config file for euclid to use other tools to provide menu and terminal functions.
File usagetutorial.md added (mode: 100644) (index 0000000..0c30347)
1 # Introduction #
2 This tutorial serves two purposes. First, it is a tutorial for people interested in learning how to use euclid-wm. Second it also serves as a quick way for those interested in euclid-wm to see how euclid works, before installing.
3
4
5 # Details #
6
7 Once installed, euclid-wm should show up in your display manager's list of sessions, so you can start is just like any other WM.
8
9 Once euclid has started, you will be greated by a big empty screen. So far so good.
10
11 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial-1.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial-1.png' height='160' width='256"' /> </a>
12
13 To get some windows to manage we can do one of two things:
14
15 > `<alt> + <enter>`
16
17 will launch dmenu (assuming you have already installed it), and allow you to start any application you like.
18
19 > `<alt> + <shift> + <enter>`
20
21 will launch xterm, or whatever you define in euclid-wm.conf.
22
23 **Caution**--if you haven't used dmenu before realize that it takes the keyboard focus until you close it (either by selecting an entry with `<enter>`, or by exiting it with `<escape>`.
24
25
26 So let's start an xterm:
27
28 > `<alt> + <shift> + <enter>`
29
30
31 Now your whole screen will be a single xterm. euclid always expands windows to take up as much space as is available.
32
33 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial2.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial2.png' height='160' width='256"' /> </a>
34
35 Note the single pixel, blue border, this indicates that that window has focus. Of course since there is only one window it doesn't tell you much; So let's start another:
36
37 > `<alt> + <shift> + <enter>`
38
39 Now you should have two xterms, stacked one on top of the other, the bottom one (which btw, is the new one) should have a blue border indicating that it is focused.
40
41 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial3.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial3.png' height='160' width='256"' /> </a>
42
43 Go ahead and open 4 xterms so we can do some neat stuff:
44
45 > `<alt> + <shift> + <enter>` (x2)
46
47 Now we have four xterms, still stacked one on top of the other.
48
49 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial4.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial4.png' height='160' width='256"' /> </a>
50
51 This is a little-bit ridiculous, as the windows are getting somewhat short. So let's move the 3rd one from the bottom to a new "track".
52
53 First, we have to focus it. Changing focus uses the standard h/j/k/l keys (left, up, down, right) with the alt key. So, assuming the focus is on the bottom (4th, window) we select the 3rd window with:
54
55 > `<alt> + k`
56
57
58 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial5.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial5.png' height='160' width='256"' /> </a>
59
60 Now we can move this window right. Moving windows the same keys as moving focus, except that it is distinguished with the addition of the `<shfit>` key. So to move this window right use:
61
62 > `<alt> + <shift> + l`
63
64 Now you will have two equal, vertically-oriented tracks. The one on the left has three stacked windows, the one on the right has a single window. The window on the right should still have focus.
65
66 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial6.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial6.png' height='160' width='256"' /> </a>
67
68 We can resize it using y/u/i/o Remember these are just like the standard movement keys, just shifted up a row. Think of them as moving the bottom right corner, so to make it wider move the bottom-right corner right. Hold:
69
70 > `<alt> + o`
71
72 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial7.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial7.png' height='160' width='256"' /> </a>
73
74 Maybe we need it way bigger:
75
76 > `<alt> + <shift> + <space>`
77
78 will toggle fullscreen.
79
80 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial8.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial8.png' height='160' width='256"' /> </a>
81
82
83 Now we are done with the middle window in the left column and wish to hid it for now, so we add it to the "stack". First we focus it:
84
85 > `<alt> + h`
86
87 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial9.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial9.png' height='160' width='256"' /> </a>
88
89 Then we minimize it to the stack:
90
91 > `<alt> + .`
92
93
94 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial10.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial10.png' height='160' width='256"' /> </a>
95
96
97 It should now be hidden, with the other two windows in the collumn taking up the extra space.
98
99 Now it should be in the stack. You can toggle the stack's visibility with:
100
101 > `<alt> + <shift> + <space>`
102
103 We can add another window to the stack too:
104
105
106 > `<alt> + .`
107
108 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial11.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial11.png' height='160' width='256"' /> </a>
109
110
111 You can change stack focus by using
112
113 > `<alt> + ;`
114
115 to go up or
116
117 > `<alt> + '`
118
119 to go down.
120
121 Bring one of them back:
122
123 > `<alt> + ,`
124
125 (Notice, , and . control putting windows into and out of the stack.)
126
127 One last thing before moving on to view:
128
129 > `<alt> + <tab>`
130
131 will flip the orientation of the layout: a vertical layout becomes horizontal.
132
133 <a href='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial12.png'><img src='http://euclid-wm.googlegroups.com/web/euclid-wm-tutorial12.png' height='160' width='256"' /> </a>
134
135
136 Okay, now about views. They are actually really simple. Views are just euclid's version of virtual desktops.
137
138 By default you are on view 1 (since you just started).
139
140 So you can go to view 1, by hitting
141
142 > `<alt> + 1`
143
144 Pretty simple. Of course you were already on view one, so nothing changed. Try:
145
146 > `<alt> + 3`
147
148 This takes you to view 3. It's blank, since you haven't put any windows there. So go back to 1:
149 > `<alt> + 1`
150
151 Now send a window to 3:
152
153 > `<alt> + <shift> + 3`
154
155 Whichever window was focused should have just disappeared, but it didn't go far, don't worry:
156
157 > `<alt> + 3`
158
159 Now you should see your window. Now we will go back to 1 a different way:
160
161 > `<alt> + n`
162
163 takes us to the previous view, since there are only views 1 and 3, and we are on 3, the previous view is 1.
164
165 But what if we want to insert 2? Let's send a window to 2:
166
167
168 > `<alt> + <shift> + 2`
169
170 Now go find it:
171
172 > `<alt> + m`
173
174 takes us to the next view, which is now 2. Do it again to see 3:
175
176 > `<alt> + m`
177
178 etc.
179
180 You can read all the keybindings on the man page.
181 You can configure them (and lots of other things) in euclid-wm.conf.
182
183
184
Hints
Before first commit, do not forget to setup your git environment:
git config --global user.name "your_name_here"
git config --global user.email "your@email_here"

Clone this repository using HTTP(S):
git clone https://code.reversed.top/user/xaizek/euclid-wm

Clone this repository using ssh (do not forget to upload a key first):
git clone ssh://rocketgit@code.reversed.top/user/xaizek/euclid-wm

You are allowed to anonymously push to this repository.
This means that your pushed commits will automatically be transformed into a pull request:
... clone the repository ...
... make some changes and some commits ...
git push origin master