Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Free Layout #28

trans opened this Issue · 5 comments

3 participants


Would it be possible for nwm to also support free-layout to some degree? There are a few reasons I ask about this.

Firstly, there a some applications that can somehow skirt around the tiling. An example is google-chrome. It has it's own bar at the top which I can grab and move the window around the screen, and though it has min and max buttons too, they do nothing.

Another issue is that some application are literally designed to be overlaid. gnome-pie is an example of this, which creates a nice pop-up menu. But nwm forces it into a tiled window, so it doesn't work right at all.

Finally, while I much prefer tiled layout myself, no doubt some people might not. I think nwm has many other merits for use then just being tiled, so if there were a way to support a free-form mode, that could be good too.


Yes, this is on the roadmap. I need to first get the JS bits rewritten to support more flexible layouts since the current JS code is a bit too entangled to do this in a nice way.

I want to add support for flexible splits, like screen and i3wm do, and also improve the popup window handling which is extremely limited right now - what should happen is that those windows should be grouped with the main window. I do a bit of detection for this - the way X11 tells you that a window is a popup is through a number of flags - but I think I've missed some of the flags.

BTW. for google-chrome, you can right click and choose "Use system title bar and borders" to get rid of the min/max buttons.


Awesome. Glad to hear it!


I've been thinking some more about this, about differences between tiling and free-layout windows, the advantages and disadvantages. In so doing, I've come to an idea that I think would provide the "best of both worlds".

Consider this scenario. Say I need to make a quick edit to a file (I tend to use gedit instead of vim). I don't really care if the window gets tilted or not b/c I will only be using it for a minute or so and then closing it. When it opens to a tile, that means my current main tile is going to get moved. But what if I was looking at a website and needed to use it as a reference for making that edit. B/c it was moved, and most likely to a smaller tile, I will have to take time to reorient: locate the moved window and possibly scroll through to find what I was just looking at before. That sucks. And that's one use case, and I'm sure there are many similar types of cases.

So in thinking about this I tried to imagine what would be the perfect solution. And I came up with letting windows open up normally with a free-layout, but if I hit [window key]-space then it will tile the windows like it does now. The great thing about this is that is gives me, the user, the choice. I can work with windows free-form if I please, and at any time tile them with a simple key press.

A footnote to this. I have tried using tiled window managers again and again. I do so b/c on the whole the use of tiles is very handy, but sadly I always end up back in a more traditional free-layout wm b/c of issues and limitations that arise with a tiled wm (a good case in point of this is using gimp). So while there is much to like about titled window managers, and much also to like about nwm in particular (beyond just its tiling), I'd much prefer to have something that offers the advantages of both, with the limitations of neither.


Yeah, that's mostly what I am after.

Right now, the problem is that the JS binding is inelegant: layouts are static functions that are applied by the workspace on its windows. I'd like to combine the two into a "layoutspace" which is basically a container that just receives windows from the rest of the system and does as it pleases with them. Each layoutspace would be it's own instance so it could remember things like window positions independently of the other layouts.

This makes it possible for each layout (including the "free layout") to do its own thing independently, and would allow for more intelligent handling of things like floats and status bars.

I'm perpetually out of time, so if you want to help, have a look at ./lib2/ and for the plans for transition. I mean I'll do what I can to get this out, but it's one of several projects right now.

@trans trans referenced this issue

this is awesome! #30


bump this would be awesome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.