For some reason (Bad marketing? Bad documentation?) this fact doesn't get much attention, but Gnome's desktop environment is written in JavaScript and styled with CSS.

https://wiki.gnome.org/Projects/GnomeShell/Development

Probably because it's only partially written in JavaScript and CSS. The link you posted is for GNOME Shell, which is primarily the menu bar and user interface components, which arguably make sense being written in CSS.

The actual window manager (which is what is implemented in this project) is separate. It's called Mutter and is written in C, like many other window managers.

I would love to use Mutter for writing a window manager. The compositing features it exposes is fantastic. My main problem is how many hooks (claws) it has in GNOME. I haven't looked at it for a long time, but does anyone know how realistic it would be to try to fork Mutter to work without GNOME (and all the associated systemd, etc stuff)?

I think the Linux Mint developers forked Mutter and used it as the base for Cinnamon.

Unfortunately, they simply forked GNOME. It still uses forks for gnome-settings-daemon, gnome-menus, etc, etc, etc. If I'm really serious about it, I should probably just look at the code in mutter and reimplement it without gnome.

That's a good point, Gnome Shell builds on lots of C code, and the project in this submission is at a different layer of the stack than it. What prompted my comment was the thought that people who were interested in a javascript window manager might also be interested in a javascript desktop environment. I mean, pulling up a javascript console and interactively poking at your environment is just a few keypresses away at all times. That's kinda cool. True, it's not "javascript all the way down". but I don't think that necessarily makes it less interesting. For example, Atom is a popular text editor amongst web developers, even though the underlying components (Chromium and Node.js) are written in C++.

Shame?

Only thing i have noticed about it is that GTK3 kept breaking themes thanks to constant changes in the CSS support.

Interesting . But for me so far nothing gets even close to the beauty and symplicity of dwm (http://dwm.suckless.org )

I switched to xmonad (http://xmonad.org/), since you can change the layout per workspace and it doesn't include a bar. (Sure, you can turn it off in dwm, but where's the minimalism in that?)

Part of the advantage for me is that dwm is written in C and pretty much it comes with no dependencies

And Xmonad is the only one that gets workspaces right in a multidisplay environment.

Not used Xmonad, but I've been saying for years Enlightenment (e17 and up) is the only window manager that lets use multiple virtual desktops (workspaces?) and physical monitors in a sane way; namely I can swap workspaces on one monitor without it effecting the other.

Gnome, KDE, LXDE, Mate, Cinnamon (and windows 10) all seem to assume that I'd only every be doing the same thing on both monitors which just seems inherently wrong.

There are three philosophies to deal with multiple workspaces and multiple monitors:

* one pool of WSs for all monitors (gnome,mate,win10)

* one shared pool of WSs for each monitor (xmonad)

* one pool of WSs for each monitor (awesome,dwm,e17)

So what xmonad has is one set of workspaces and each monitor can pick one from the shared pool! It's so great to have a WS dedicated for WWW on a side monitor and when something important comes up, I can bring that WS to the main monitor. Not easily done with the last idea.

Oh, very clever; I didn't realise there were 3 distinct behaviours. Options two and three seem to make sense; I find it hard to believe anyone actually wants type 1. I'll definitely have to have a play with xmonad now :)

macOS also gets multi-monitor right. It even gets it right if your monitors have different DPI.

i3 also has excellent monitor/virtual desktop support.

I used DWM and derivatives (Awesome, etc) for some time but I didn't enjoy the automatic layouts. The split between primary and secondary areas felt clumsy to me.

I recently switched over to bspwm [0], and I really like it. Instead of automatic layouts, all areas can be split horizontally or vertically (similar to e.g. vim or tmux windowing). The layout tree can be manipulated in various ways, but the only on I use is rotate (ie. change vertical split to horizontal or vice versa). I don't have any status bars or launchers.

It's not all good, though. Just recently the config syntax changed and it was somewhat annoying to upgrade my old config to the new syntax, albeit the new syntax is much better. Hopefully it stabilizes soon.

It's also split in a funny way, so that bspwm only manages windows. It doesn't even listen to the keyboard, but typically uses another app (sxhkd [1]) for listening to the keyboard and launching a process (bspc) to control the wm. This is elegant and unix-ey but responsiveness suffers under heavy load. On the other hand, it's not tied together with a scripting language like e.g. Awesome is bound to Lua and XMonad to Haskell, which is nice.

Status bars and launchers are done with external apps but I don't use any at the moment. I do miss a desktop activity indicator a little, though (tint2 didn't work out of the box with bspwm, lemonbar was too hacky for my taste).

[0] https://github.com/baskerville/bspwm [1] https://github.com/baskerville/sxhkd

Hmm... "Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though."

It's really not too bad; just edit the config.h, "make", and put the binary somewhere in your $PATH. Changing the font, colors, keybindings, etc just requires modifying some strings and arrays.

The "Why?" section seems to answer the question "What?".

Would have expected either "Why you should use this", or "Why I/we wrote this".

There sure is a shitload of C in this node.js program.

Keep in mind that this is pretty old, and no longer compiles against recent Node.

Last commit 11 months ago. Node is certainly a moving target. Running in fact.

cwm[1] is by far the cleanest wm I've used. It reeducated me on what a wm should be. Focus by hover, no bars of any kind, move and resize with shortcuts instead of searching for the clickable area, extremely lightweight, good straightforward configuration (opposite of openbox).

[1] https://www.google.com/search?q=cwm+window+manager

for me "Javascript" + "Window manager" will always mean pyro (http://web.archive.org/web/20100626182331/http://pyrodesktop...). so much wasted potential there :(

So how long until somebody makes a kernel in Node?

You mean like this?

http://www.espruino.com/

One example of bare metal JavaScript.

The biggest problem with such systems are more political than technical.

We have tons of CPU cycles to spare compared with what Burroughs, Xerox PARC, ETHZ and many other similar systems required.

As an example, the Xerox Alto used for Smalltalk-80 had 512 KB of RAM with 4 74181's running at 5.88 MHz.

Just wait until after the nuclear world war in the early 2020s.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

There are already emulators that work in JS, that said, I don't know that it'd work for anything not emulated... As much as I love JS, I'm even a bit of a fan of electron based apps. That said this kind of integration doesn't make as much sense to me, it's interesting, but don't know how far it should ever go.

I can se leveraging web/js as part of skinning/theming a window manager ui, but not sure about having it this far down the rabbit hole.

The day 60GB of RAM is the norm. Just wait till embedded development shifts to node.

For the "bigger" embedded platforms (rpi and similar), node is pretty serviceable... There have been other efforts to get JS based engines working well too. It depends on how you define embedded.

I was a little angry with my browser so that was meant to be an insult.

JS (not node) is usable for embedded coding. An example would be http://www.espruino.com/. Newer boards that come on Kickstarter typically support JS since it's a great intro language for coding especially for kids.

It's funny, but I like JS a lot, still think that Python is probably a better learning language... there's enough sharp edges in JS, that I don't think it's great for starting with, other than it's accessible, and combined with a browser, close to instant gratification.

Teaching JS to kids? Let's hook Dijkstra up to a dynamo, he'll be spinning in his grave fast enough!

I think it's great in the sense that you can easily make apps, games etc. which is good for getting kids interested quickly. Once their hooked, we can push them to some of the "better" languages.

As long as Python actively refuses to support real constants among some other immutability related features, I think the more recent versions of JS are going to get past Python in sheer elegance of code.

I'm inclined to agree to some extent... I think that JS can be beautiful and intuitive. However, I've seen too many instances of the following.

    var bazCopy = [];
    for (var i=0; i<bar.baz.length; i++) {
      var orig = bar.baz[i];
      bazCopy[i] = {
        fizz: orig.fiz,
        buzz: orig.buzz
      };
    }
    parentCopy.baz = bazCopy;

Over map/reduce/filter, and the like... Sometimes doing code reviews on pull requests is exhausting.

> Just wait till embedded development shifts to node.

It already has. See Tessel (now on v2 of their board), and the Espruino which powers the pretty sweet Puck.js board.

If you're Microsoft with their Azure/IoT setup, it's already happening. I've been spelunking in their SDK and it makes me want to tear my hair out.

I'm working with Cortex-M0/M3 devices kicking bytes over wifi modems, and Microsoft believes a "device" is a desktop-class SoC with an Ethernet jack running Node.

Well you could use Java instead. :)

http://www.microej.com/products/

You know, in an alternate universe where ARM Jazelle took off, that might not be so bad.

But in this universe I'm all out of hair.

There is such alternate universe, even if not in large scale.

It is composed by the likes of PTC, IBM J9 Embedded or other alternative languages like .NET MF and Oberon.

But I do conceded it is not an option most of the time.

Good luck with the project.

Close: https://github.com/runtimejs/runtime

There's another project but I'm having a hard time finding the link again.

I think you mean this one: https://node-os.com/

No, I meant one that's actually a kernel running on duktape or something.

OT, but does anyone have any suggestions as to a tiling window manager which can effectively use the mouse?

I personally use awesomewm because I find it's easy to use with either keyboard or mouse. I've not tried other ones in a while so it could just be a case that I'm used to it though. Thinking about it, by "using mouse" I still need to use the modifier key...

By default:

Mod+Left click = move window

Mod+Right click = resize grid (when tiled) or window (when floating)

awesome[1] has pretty decent mouse support, as far as tiling Window managers go.

[1] https://awesome.naquadah.org/

Windows 10 is pretty good IMO.

That's what I'm using now, but the limitation of 4 grid cells is somewhat inconvenient. Ideally I would like something just a bit more powerful.