I think the architecture assumes all loaded kernels are trusted, and imposes no isolation other than having them running on different CPUs.

Given the (relative) simplicity of the PoC, it could be really performant.

I did the same thing back in college, when I was in a lab. We wanted to do some research on Wi-Fi signals, and I happened to own a bunch of Wi-Fi adaptors produced by SomeSmallTech Co. Ltd., which featured relatively new Atheros chips and didn't have Linux drivers at the time.

So I sent an email to the company's public email address, asking for some datasheets, "for science". To my disappointment, presumably a PR person replied that they "don't have a company policy to collaborate with academic research". (But they did send a quick reply, kudos to that.)

Funnily enough, years later I ended up working for said company. Naturally, when I first logged into the company network, I searched for the datasheets I asked for. There were "classified" watermarks all over the PDFs :)

[1]: https://haltp.org/posts/owl.html

[2]: https://haltp.org/posts/owl.html#heading26

I agree. I considered dynamic offsets, in an effort to declutter the labels, but found it even more confusing. Maybe I should do more experiments on this.

> but where the labels were laid out it just looked like an inviting right-aligned label on the clickable tabs themselves

The labels are left-aligned by default (except in `frame-hinter`). I think you can try some combinations of the `:anchor` and `:show-highlights` options[1] to see if they work better for you.

[1]: https://agent-kilo.github.io/jwno/ref/built-in-modules/jwno-...

Edit: Wrong link

Sorry for the confusion. I think switching to another leader key, such as LAlt or RCtrl, should fix the issue.

Meanwhile you can try to change leading `RAlt` to something else, like `Win + H`, and see if it works. There may be a bug that gets triggered when only modifier keys are mapped.

Do you mean reserving screen space for the on-screen keyboard? If that's the case, you can try to "transform" the top-level frame (a frame that tracks a monitor's screen area), either in the REPL or in your config: https://agent-kilo.github.io/jwno/cookbook/adjust-top-level-...

> Using example-config.janet I tried pressing RAlt or RAlt+K and I get the UI hint shortcuts list coming up, but none of them seem to do anything

Can you please file a bug report and attach relevant logs? You can write logs to a file by starting Jwno like this:

jwno.exe --log-file C:\jwno.log --log-level debug --no-console your-config.janet

There should be some interesting logs when you press one of the UI hint shortcuts.

> Fwiw, as a newbie I found it a bit intimidating/off-putting that it doesn't work out the box without choosing a config file. That's quite a lot of extra cognitive effort and link-clicking before you can try it out.

I totally understand. But I chose to not include a default config in the executable, because I thought a window manager is a... personal thing. It should evolve with your habits and workflows, so the default config will most likely get changed to something dramatically different anyway. I can be wrong though.

My StumpWM is heavily customized though, and I mostly modeled Jwno's behavior after my own config, so it may not be what you expected at all.

But that's one of the reasons I like Lisp and things built in Lisp: They are so flexible, you can sometimes build something based on the original thing, while it feels completely different from the original.

> my monitor seems just the right shape/resolution for the standard Windows splits to be suboptimal

Do you use an ultra-wide? In that case, Jwno has no OOTB ultra-wide support, but there's a section for adjusting it in the cookbook[1].

[1]: https://agent-kilo.github.io/jwno/cookbook/adjust-top-level-...

Jwno's internal data structure has these levels (higher-level comes first):

Root - Virtual Desktops - Monitors - Normal Frames - Windows

So monitors are part of a virtual desktop, and every virtual desktop has the same layout that reflects your physical monitor arrangement. When you switch virtual desktops, all monitors switch to the new desktop at the same time.

[1]:https://agent-kilo.github.io/jwno/frame-tree/frame-nodes.htm...

[2]: https://github.com/agent-kilo/jwno/blob/master/example/tutor...

It's a quick-and-dirty PoC with lots of caveats and limitations though. E.g. it works only for a single monitor. I don't think we can clip windows to a "view port" on Windows (the OS), so this may never be as nice as PaperWM, Niri etc.

* By default, Komorebi uses dynamic tiling, while Jwno uses manual tiling.

* Komorebi has workspaces, Jwno works with Windows native virtual desktops instead.

* Komorebi uses IPC and native system command line to send commands, while Jwno usually operates all by itself.

There are definitely other details that are important to you, but these are the things that immediately came to my mind. I don't run Hyprland so can't really comment on that.

Maybe the most "opinionated" things in Janet are the ev stuff and fibers. I think they're done right though, you just need to be careful with the event loop when embedding Janet.

I think Jwno's REPL module is so important, I specifically changed Jwno's architecture at one point to make it work.

This is exactly how I feel about Janet too. I don't think I have enough experience on Clojure or Lua to comment on them, but I got attracted to Janet almost immediately.

Working on Jwno also confirms my first impression on Janet: It's really a practical language. The tooling has some room for improvement, but the language itself can get things done - usually fast and easily.

I read[1] about Janet[2] some time ago, then immediately got impressed by the enthusiasm of its community, and by the language itself, so I started playing with it.

At the time I was searching for a tiling window manager for Windows, and unavoidably the idea of scratching my own itch with Janet got hold of me, so Jwno was born.

Simply put, Jwno is a keyboard-driven tiling window manager for Windows, scriptable with Janet. But since it has a complete Lisp runtime, and a thin wrapper library for Win32 APIs[3], you can certainly do much more with it.

I hope you'll enjoy playing with it as much as I enjoyed building it.

And yes, I use StumpWM on the Linux side, by the way.

[1]: https://ianthehenry.com/posts/why-janet/

[2]: https://janet-lang.org/

[3]: https://github.com/agent-kilo/jw32

Comments URL: https://news.ycombinator.com/item?id=44042490

Points: 297

# Comments: 103

I read[1] about Janet[2] some time ago, then immediately got impressed by the enthusiasm of its community, and by the language itself, so I started playing with it.

At the time I was searching for a tiling window manager for Windows, and unavoidably the idea of scratching my own itch with Janet got hold of me, so Jwno was born.

Simply put, Jwno is a keyboard-driven tiling window manager for Windows, scriptable with Janet. But since it has a complete Lisp runtime, and a thin wrapper library for Win32 APIs[3], you can certainly do much more with it.

I hope you'll enjoy playing with it as much as I enjoyed building it.

And yes, I use StumpWM on the Linux side, by the way.

[1]: https://ianthehenry.com/posts/why-janet/

[2]: https://janet-lang.org/

[3]: https://github.com/agent-kilo/jw32

Comments URL: https://news.ycombinator.com/item?id=43912246

Points: 4

# Comments: 1