Giter VIP home page Giter VIP logo

xest-window-manager's Introduction

Logo

Xest Window Manager

Are you a user? Check out Xest's website at https://jhgarner.github.io/Xest-Window-Manager/

Are you a developer? Keep reading!

The Code

Who Should Read the Source Code?

Xest is a window manager written in Haskell. The goal of this codebase is to be at least partially accessible to other Haskell users who are familiar with some language extensions. Since I've been the only contributor though, there is almost no way that goal has been met. I used this codebase as a testing ground for new practices which means a lot of the code will be filled with strange patterns and obtuse logic. If you're trying to understand the code and something doesn't make sense, let me know or open up an issue.

I'm always happy to answer questions about Xest no matter how silly they may seem. Feel free to open up issues, join the Matrix chat, or check out my profile for how to contact me if you have any questions. I'm also always happy to hear what ideas you might have about making the code more readable, robust, or performent.

What should I know if I want to contribute?

If you've never seen the Haskell language before, jumping into this codebase is probably a bad idea. If you have a little bit of experience, I would recommend taking a look at some of the files in the src/Tiler/ folder. All of the functions in there are "pure" in that they only modify internal data structures and don't require knowing much about Xlib.

The weirdest things you will find in those files are the uses of "Fix" and "cata". I would highly recommend reading https://blog.sumtypeofway.com/posts/introduction-to-recursion-schemes.html if you haven't seen them before. That blog series fundamentally changed how I thought about recursion and ADTs. I likely would have given up on this project if I hadn't found that way of organizing the code.

If you want to look at the other parts of the codebase, you'll need a basic understanding of what the X11 protocol is. I would recommend https://magcius.github.io/xplain/article/ and https://jichu4n.com/posts/how-x-window-managers-work-and-how-to-write-one-part-ii/ as good descriptions of X11 and how window managers work. The Haskell X11 library is pretty close to the original xlib so any docs related to xlib will probably help as well. I found myself using the Tronche website a lot for xlib documentation as well as the XMonad source code.

ICCCM and EWMH are protocols built on top of X11 and tend to get sprinkled around the src/XEvents.hs code. The official documentations for those protocols are probably the best resources for learning about them.

Xest currently uses freer-simple as its effect system. If you've never seen free monad based effects before then it might look a little weird. Luckily, a lot of people have written about free monads and freer-simple so there should be good tutorials online for it. You can avoid most of the gross effect code by staying out of the base/DoAll.hs file. You'll see stuff like Members '[Thing, Thing2, etc] m in a few different files. Basically, that lets you operate in a monad that has the capabilities defined in the list.

Why not Wayland?

X11 is a bit of a mess and Wayland is almost certainly better. I chose not to make a Wayland compositor because the Haskell tooling is extremely immature. This was my first foray into Linux window management and having to deal with all sorts of new technologies and lacking documentation would have been awful.

The other reason I didn't pick Wayland is that I expect my window manager to be fairly flashy. On X11 I can use Compton to get really nice blurring, fading, vsync, and shadows. On Wayland I would have to write all of that code myself. Since I have Nvidia cards in my devices, I also have to deal with all of the problems they've created.

For those reasons, Wayland seemed like too much to tackle. With that said, I am happy to work on making Xest more backend agnostic and adopting Wayland when it looks like there's a path forward for the tooling on Haskell. If someone knows that path, please share it with me.

xest-window-manager's People

Contributors

anlogan avatar capelin avatar edwargix avatar jhgarner avatar josephmckinsey avatar sumnerevans avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

anlogan edwargix

xest-window-manager's Issues

Floating Tiler

Add a floating tiler where one element is the background and the rest are on top.

Add a maximized Tiler

The maximized tiler acts like a mix between input controller and the fullscreen tiler. Like the input controller, there can only ever be one of them. Any window not below the maximizer doesn't get displayed. The maximizer must always contain the input controller.

This would make the current workflow of using a million full screen tilers less painful.

Honor Struts

Desktop components might ask to take over parts of the screen. Xest should let them do that and shouldn't draw over them.

Performance Problems

In the default config, try changing from normal to insert mode very quickly and watch your CPU usage in something like Htop. Three problems appear:

Xorg: This process sees high CPU usage because we're sending the server a large number of commands. How do we reduce the number of commands we're going to send?

Xest: CPU usage on this process skyrockets as well.

Other programs: They don't seem to like being moved for the borders too often.

Marks

ChangeNamed is a weird function. It only really has any use on Horizontal Tilers yet, because it's an action, it can be applied to anything. ChangeNamed also became less string over time. Instead of taking a string, it has since switched to taking an index.

The idea here is to borrow the concept of a mark from Vim. A mark in Vim lets you to link arbitrary points in your file with keys on your keyboard.

Marks in Xest would work in a similar way. The user could place them in the tree and as long as they exist, could jump to them from any other place. Marks would be represented in the tree as nodes with a single child. Jumping to a mark would place both the IC and the Monitor right inside of the mark. It's extremely useful to have extra marks be automatically created by other Tilers. For example, changing workspaces using a Horizontal Tiler and zooms is extremely useful. The simplest idea is that some mark characters are reserved. If you press one of those, the Tiler gets to decide what happens. Otherwise, the entire tree is searched.

Multimonitor Support

I have no idea what it will do now, but it definitely won't be the right thing. This also requires figuring out what the right thing is.

Add full screen window support

Games like Factorio make the entire screen black, but don't take up the entire space. There is probably some hint that Xest is missing.

Compiling is slow

The Base.hs file uses many gigs to compile and moves really slowly. That might be fixed by splitting it up into separate modules.

Floating Things

Windows that open up floating dialogs usually look really bad. One idea is to auto insert a hovering Tiler if a new window is transient for something we're managing.

Move between directional windows

Currently, the mouse is the only way to change focus. Since Workspaces are implemented as Directional Tilers, we need to provide ways to do it with the keyboard as well.

Open questions:

Should every directional tiler share the same keybindings?

Linting

I should find a good linting workflow and somehow get that set up with Github Actions.

Use Tiler composition

Inspired by Xmonad, why not use compostion of basic Tilers to create bigger ones. For example, instead of having a directional tiler with a few different modes, have a single horizontal tiler and a rotation tiler.

Add "Formal" Verification

I'm adding "Formal" Verification to the list of cool things I've read about on the internet and want to implement. Specifically, the Ghosts of Forgotten proofs method of doing things. It allows you to assert various truth's about your code in what appears to be a straightforward way without having to fight the type system. Those "Facts" could then be unit/property tested giving the best of both worlds. Figuring out what to prove will be hard though.

Edit: Also, just adding testing that compiles would be cool...

Steam crashes Xest

It seems to crash during a ConfigureWindowEvent being sent by a window that hasn't been mapped. The actual error is in getting the window attributes. I can't really tell why that's a bad window. As with anything in Xlib, it seems like I might be running into some race condition where the configure event is triggered but the window is destroyed before my code runs. If that's the case, I probably need to set up real error handlers. More likely, I'm just doing something bad in my code.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.