Rendered at 20:59:13 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
NitpickLawyer 14 hours ago [-]
I really like the amount of exploration going on right now in this space. Even if this particular project (or the many terminal trackers/mergers/splitters, session managers, etc) don't end up being the thing, exploration is useful and might inform the next platforms.
The IDE has been "static" for most of the past ~20 years, with obvious improvements, but they were always incremental. The kind of exploration we see now is a bit more extreme, and I like it. It also seems like a lot of people are looking for alternatives, and I like some ideas. Even the funky ideas (I once saw a post comparing and proposing IDEs to follow RTS games UI) are interesting. Who knows what might stick.
BlueBerry2001 13 hours ago [-]
Yeah, I agree. I think we are in an interesting phase where people are rethinking the “IDE as one fixed rectangle” model.
Cate is one attempt at that from the spatial side: persistent canvases, terminals, browsers, notes, agents, docks, tabs, splits, worktrees etc. It may not be the final shape, but I think there is room for more experimentation around how long-running AI/dev workflows are organized.
norman784 12 hours ago [-]
I was exploring a similar approach, but not focused on AI, my idea was basically group projects by workspace, where each workspace has a path and is related to a project, you can spawn terminals, editor and web browser windows in this workspace, the web browser cookies and such should be associated to a workspace, that way it will not leak between workspaces and also this allows you to have different sessions opened in different workspaces.
Unlike Cate, the windows of the terminals, editor, browser, etc, each one was handled similarly like Niri tiling scrolling window manager, that way you can use the keyboard to move around, where you can group windows in a column or split them, have different sizes, is not quite where you have a free form, but an horizontal collection of windows that you can scroll.
hnlmorg 7 hours ago [-]
I’m building something like this right now.
I’m already using it as my primary terminal emulator and have recently just been adding LSP support to the code editor.
jrgd 11 hours ago [-]
I would love to have something like this
I used itermocil when i was on macos, that was limited to iterm windows.
On Linux, I have been playing/exploring with Hypr but without much success so far.
mapcars 12 hours ago [-]
Now with AI I find myself in need for a space that can combine multiple repos into a single "project". For example for debugging an issue across the system, or asking it to verify if FE/BE communication schema has any mismatch, or describing the complete feature flow from one end to another.
Is Cate's canvas per git-repo or can I add multiple?
2muchcoffeeman 11 hours ago [-]
Maybe Repomix?
13 hours ago [-]
jauntywundrkind 5 hours ago [-]
Excellent post. Thank you.
I love looking through awesome-web-desktops. Most aren't infinite canvases but they are canvases, canvases of programs. There's fun stuff. UI paradigms being cooked up. I'll pitch in particular AetherOS, as being a neat web desktop that also is interestingly connected, networked, which is neat.
https://github.com/syxanash/awesome-web-desktopshttps://bsky.app/profile/aetheros.computer
I do think we need to ask a little more "what next?". Taking Niri as a real desktop example, it's just so good, such simple but enjoyable new bones for a doing computing atop. So close to what was but so unique and nice. It intuitively connects me to the many many what ifs all around, makes me feel like there's such imminent possibility.
Especially today, who can make a UI that can be spoken well with, that is conversationally capable: that frontier feels barely explored. 9p is by far far far the most agentic desktop we have ever had, looked at this way. So beyond how it looks and works, how do computing surfaces express themselves?
verve_rat 12 hours ago [-]
Agreed. I'm actually excited to hope for a cambrian explosion of IDE experiments.
LLM powered visual diagramming of the code as you work? The ability to edit the diagrams and have tje LLM apply that back to the code? Visualisation of test coverage over the UI you are working on? Allowing you to attach user submitted videos of bugs directly to tests in the code?
I don't know if any of that is a good idea, but I really hope a bunch of people try.
xlii 11 hours ago [-]
I'll piggyback on something someone else here on HN commented (can't cite, sorry!): I can immediately recognize vibe coded projects by their visual design.
It's a weird skill but after seeing website, screenshot etc. I need only couple of seconds to make an opinion. I then look into history of project etc., though it rarely contradicts first impression.
I think I do this because I don't trust thus I don't want to use such projects. Not because vibe coded/vibe-code driven projects are inherently bad (they aren't). Because I think low self-investment translates to low ongoing self-interest.
Since all software is buggy to some degree, I'm certain I'll find a dealbreaker that will never be addressed, and risk is rarely worth it.
m00dy 11 hours ago [-]
I know that feeling, it's like pattern recognition
BlueBerry2001 6 hours ago [-]
[flagged]
TonyStr 14 hours ago [-]
Why use this instead of a native window manager? GNOME, KDE, Windows, MacOS, i3 all support virtual desktops where your window layouts are preserved
hnlmorg 7 hours ago [-]
That’s a fair question but I can think of one big advantage of going this way and that’s to do with distraction-free workspaces.
To use a comparison, have you ever picked up your phone to enter an TOTP / one time auth code and then accidentally found yourself texting a friend, or some other non-work activity. It’s particularly easy to get distracted if you have an open notification you didn’t see until you went to use that one time code on your phone.
Having a desktop app for your workspace helps hide Slack and other distracting items while context switching between different productivity apps.
kidfiji 14 hours ago [-]
I feel that this single-pane-of-glass approach works better for some folks' mental models
BlueBerry2001 13 hours ago [-]
Yeah, that’s basically the mental model I’m aiming for.
Not “replace the desktop”, but one pane of glass for a specific project/workflow. Some people prefer strict OS-level windows, others seem to think better when the project is laid out spatially and persists between sessions.
BlueBerry2001 13 hours ago [-]
Because native virtual desktops still mostly preserve app windows, not project context.
Cate is more scoped: one workspace per project/folder with terminals, browser previews, editors, notes, agents, worktrees, docked tabs/splits, and restored panel positions. It’s not meant to replace GNOME/KDE/macOS/i3 globally, more to keep the messy project-specific layer in one persistent place.
throwthrowuknow 11 hours ago [-]
Window layout isn’t the key feature, creating a spatial map of open files and other resources is.
PetitPrince 13 hours ago [-]
I conceptually agree that managing windows should be the task of... the window manager, but at the same time it's easier and lower friction to both develop inside of an app and get some user to test new features
BlueBerry2001 13 hours ago [-]
Exactly. I agree that the OS/window manager is the “proper” layer in theory.
In practice, building it as an app makes experimentation much easier: cross-platform, lower friction to try, no need to replace your current WM, and we can iterate on workspace-specific features like terminals, browser panels, agents, Cmd+K search, worktrees, docking/tabs/splits, etc.
v3ss0n 13 hours ago [-]
agree , it should be WM isntead of a very limited electron app.
BlueBerry2001 13 hours ago [-]
I get that. A native WM version would be interesting, especially for performance and deeper OS integration.
For now Cate is intentionally an app because it is easier to try, cross-platform, and focused on project-level workflow rather than managing the entire desktop. But I agree the boundary between spatial workspace and window manager is a real discussion.
Cate is an open source desktop workspace built around an infinite canvas. Instead of constantly switching between terminals, editors, browser previews, docs, and AI tools, you arrange everything spatially in one place.
Big improvements since the earlier posts:
docking, tabs, and splits
detachable native OS windows
git worktree support
unified Cmd+K search
much smoother rendering/performance on larger canvases
AI provider + MCP integration
Stack:
Electron, React, Monaco, xterm.js/node-pty, Zustand.
Runs on macOS, Windows, and Linux. MIT licensed.
Would love feedback from people with heavy multi-window or terminal-based workflows.
xerox13ster 11 hours ago [-]
> Been sharing progress on Cate here for a while
8 days is a while?
I checked because I’ve had a similar idea for several years and wanted to see the earlier discussion on your shared Cate progress.
There’s nothing. You linked it 8 days ago on a brand new account and it died.
BlueBerry2001 6 hours ago [-]
Fair point. The wording was a bit clickbaity, I get that.
It’s definitely not dead though. Quite the opposite: the project is actively growing and improving. The first post didn’t get much traction, but we kept working on it, fixed a lot of rough edges, and v1 is in a much better state now.
I should have phrased that more clearly.
mrgaro 12 hours ago [-]
I'd love to get this as a self-hosted web service, so that I could access my infinite terminal canvas from any browser. It should of course held the sessions in the background even when I'm not connected.
BlueBerry2001 12 hours ago [-]
That would be a really interesting direction, and I agree it fits the idea well.
Right now Cate is a local desktop app because we wanted the first version to work closely with local projects, shells, files, node-pty/xterm, browser panels, Monaco, git worktrees, etc.
A self-hosted web version would need a different architecture: a backend that owns the PTY sessions, keeps them alive when the browser disconnects, handles auth/security, and syncs the canvas state to the client. Definitely possible, but a bigger shift than just “put the current app in the browser”.
Long term I think remote/headless workspaces and reconnectable sessions would make a lot of sense.
Yokohiii 12 hours ago [-]
Is https://cate.cero-ai.com supposed to be an functional demo? Because most basic widget handling either doesn't work or is broken.
jon-wood 11 hours ago [-]
It shows a lot of promise but yeah, the actual app is just as broken. Love the concept and I'll be keeping half an eye on where it goes but right now its simply too janky for me to use it on a daily basis. If the author is reading here's a few things that came up for me within about 2 minutes of using it:
- I can't scale windows by grabbing the top edges like I can on the bottom/side edges.
- The command palette provides me with a list of open windows but selecting them doesn't do anything.
- A pinch to zoom gesture zooms in and out over unfocused panes but scrolls on focused ones. A keyboard modifier key I can hold that puts me into workspace pan/zoom mode regardless of where my cursor is would be great.
- It seems really erratic as to whether grabbing a pane and dragging will move it, scale it, or do nothing at all.
- The displayed cursor quite frequently has no correlation with what it's going to do.
- The mini map should really allow me to drag around my viewport on it rather than clicking and jumping to a specific place.
I really want to love this, its a great concept for working with complex projects but as I say right now its simply not there. Here's a few bonus things I'd love to see:
- The ability to rename terminal windows. Terminal 1,2,3,N is going to be unusable almost immediately.
- A jump to pane function (probably triggered via the command palette pane list) which allows me to select a specific terminal/editor/region/whatever and be jumped straight to it.
- Please add Kagi as a search engine option.
- As someone else has mentioned the real killer feature here would be the ability to run Cate with a remote backend, either accessed via a web browser or the Electron wrapper. I routinely use both VSCode devcontainers locally and remote machines over SSH and I'd love to be able to have a bunch of open sessions I can just jump back into.
BlueBerry2001 6 hours ago [-]
[flagged]
BlueBerry2001 12 hours ago [-]
[flagged]
piterrro 13 hours ago [-]
I like the idea, my fear is however that the lack of structure will cognitively overload my brain and at some point every canvas will become a mess. Think about how to expire unused/old windows. Maybe let use set a limit so that at some point they are forced to remove old window when they want to open a new one.
I have a miro board as a notepad, I constantly add new stuff but at the same time its unmanageable.
Another example could be browser tabs, since there's no limit my current window holds approximately 60 open tabs which (which I dont use ofc) - this is the effect of chrome not having a native way to save stuff for later in a semantic way (you cannot search through bookmarks the same way you would search through google).
The success of this project will be defined by how well and easy users are able to retain the context (or content) of their canvas.
BlueBerry2001 13 hours ago [-]
That’s a valid concern and probably one of the biggest risks with an infinite canvas.
The goal is not “infinite mess”, but persistent context with enough structure: docking, tabs, splits, search via Cmd+K, detachable panels, project-based canvases, and restored layouts. I also think things like expiry/cleanup, saved views, folders or semantic grouping would make sense over time.
Retention of context is basically the whole product question here.
prox 13 hours ago [-]
I like Obsidian for note taking and it does have an infinite canvas, but it feels bolted on. I would love to have a more canvas first note taking app, maybe with folders for visual declutter.
Navigation in default Obsidian is one of the weakest points imo
BlueBerry2001 13 hours ago [-]
Agree. Obsidian’s canvas is useful, but it still feels more like an extra feature inside a note app.
Cate is trying to be more canvas-first for active dev/workflow use: terminals, browser panels, editors, notes, agents, worktrees and project layouts all living in the same spatial workspace. Visual decluttering and navigation are definitely important parts of making that not become chaos.
I did, but I would prefer a more local first program.
midenginedcoupe 13 hours ago [-]
I'm confused.
The homepage explicitly calls out that "Cate is not a window manager replacement" yet as far as I can tell pretty much all its features are window management. And the ones that aren't would be better off living in their own dedicated apps anyway (or aren't going to replace people's preferred editors or terminals).
The infinite canvas idea sounds cool, and I'm not aware of a window manager that lets you zoom and pan around a massive "desktop", but it really does sound like the cool bits would be better implemented as an actual window manager. Then we can keep using our favourite IDEs, terminals, editors, etc. etc which is where the actual friction for change sits, and have the cool infinite canvas/docking/arranging stuff on top.
jon-wood 11 hours ago [-]
I totally agree that this should be a window manager (and I'd really love it to be one, my brief poke at this has just made me want my entire operating system to work like this). I can see why you'd start by prototyping at least in a single app context though, it gives you immediate cross platform support rather than just targeting Linux which is the only place you can really build a window manager this different to what the OS expects, and its just a generally more tractable problem.
BlueBerry2001 13 hours ago [-]
That’s fair. I probably need to explain that distinction better.
Cate is not trying to replace the OS window manager globally. It’s more a project workspace where terminals, browser previews, notes, agents, editors, and docs can stay arranged together and be restored per project.
A native WM version would be interesting, but the app approach makes it easier to test the workflow across macOS, Windows, and Linux without asking people to replace their desktop setup.
philipallstar 13 hours ago [-]
Why would you say a window manager would be better? I can imagine for power users maybe, and definitely for architecture astronauts, but being able to have workspaces managed by an app that can control all of a set of "windows" being opened at once depending on what work is being done is a lot more functional. And you can have your email etc open in a separate real OS window.
midenginedcoupe 12 hours ago [-]
Pretty much all of it, really.
If you want their fancy windowing stuff, I think you also need to use their apps. Terminal, IDE, etc etc. Switching to a different terminal is friction, switching to a different IDE is a really big jump. My bet is most people aren't going to switch to a different IDE just to get different window management behaviours. And if the bundled IDE is brilliant, then you can't use that without this window management coming along for the ride too.
The differentiator for this project is the window management. Don't restrict that to just the re-implemented apps within the walled garden, and then you have the behaviour implemented in the right place.
fhennig 11 hours ago [-]
I think the infinite canvas is a key feature, so you couldn't just disregard this to make it into a window manager.
jon-wood 11 hours ago [-]
You could absolutely (on some platforms) make a window manager which is an infinite canvas.
fhennig 7 hours ago [-]
But at the moment it's cross platform.
sekihan 9 hours ago [-]
[dead]
SwiftyBug 10 hours ago [-]
I understand this is project-scoped and not intended to replace a window manager, but it just occurred to me that this concept could be a cool experiment for a Hyprland plugin. Instead of multiple workspaces, a single, infinite one that could be navigated by dragging and zooming in and out. I would probably hate to use that, but I supposed it would be a lot of fun to develop it.
cl3misch 12 hours ago [-]
This seems to be very similar to the (sadly abandoned) Haystack editor [1]. I was a bit surprised to find no mention of Haystack in the README or here in the comments. Maybe the idea of having a "canvas editor" and building it on VS Code is not that unique...
Thanks for the pointer, I actually didn’t know Haystack before. Looks like it belongs in the prior-art / inspiration section, so I’ll add it to the README.
From a quick look, I agree there is overlap around the canvas editor idea. Cate is aiming a bit more at the broader project workspace layer: terminals, browser previews, editors, notes, agents, git/worktrees, docking/tabs/splits, and persistent layouts around a project.
But yes, fair callout. Appreciate the input.
cl3misch 5 hours ago [-]
> Maybe the idea of having a "canvas editor" and building it on VS Code is not that unique...
Re-reading my comment made me realize it sounded condescending, where it was actually meant to emphasize that a canvas editor is a great idea! So I am very glad that there is development is this space.
Just felt the need to clarify this...
dontfeedthemac 14 hours ago [-]
Nice, but I'd love to see something more native. Maybe rust written for better performance without using any sort of GPU acceleration to keep the battery running longer on laptops. Even better if we can have a headless setup where you can connect from any computer without using VNC or what's so ever. Probably can also have collaborative sessions and have AI-assisted sessions with a 2nd cursor rendered like in the OpenAI examples weve seen lately.
BlueBerry2001 13 hours ago [-]
Yeah, I understand that direction. A more native/headless or Rust-based version could be interesting long term, especially for performance and battery life.
For v1 I kept it as a cross-platform desktop app so people can try the workflow without changing their OS setup. But collaborative sessions, remote/headless workspaces, and AI-assisted sessions are definitely in the same general direction as what Cate is trying to explore.
I see Cate also uses node-pty. I didn't know what psuedo terminals were before, it's cool stuff
BlueBerry2001 12 hours ago [-]
Nice, I just checked terminaldraw. Very similar core idea, but interesting that you used tldraw more directly as the canvas engine.
Cate is a bit broader in scope: Electron desktop app, persistent project workspaces, node-pty/xterm terminals, browser panels, Monaco editors, docs, git/worktrees, docked tabs/splits, and now agent panels as well.
PTYs were a fun rabbit hole. The basic idea is simple, but making terminals feel native inside a canvas is where it gets tricky: lifecycle, resize behavior, restoring sessions, shell fallback, scrollback, performance, and not breaking when panels are moved/docked/detached.
Cool to see someone else exploring the terminal + canvas direction too. I’ll take a closer look at your repo.
jon-wood 10 hours ago [-]
If you haven't already it may be worth looking at https://github.com/coder/ghostty-web which wraps libghostty in an xterm.js compatible wrapper, the focus for Ghostty has very much been the sort of things you're mentioning so it'll hopefully make a solid foundation.
JrProgrammer 12 hours ago [-]
Cool project!
I've been playing around with a couple of different implementations of an infinite canvas.
One of the reasons why I did not go with an HTML based approach is because the XY translation gets really laggy with a couple dozen items.
Is that something you thought about and accounted for?
BlueBerry2001 12 hours ago [-]
Yeah, that was one of the main challenges and still is.
We chose Electron because the goal for v1 was to make Cate easy to try across macOS, Windows, and Linux without asking people to change their OS setup or use a specific window manager. A native implementation would probably give us more control and better performance in some areas, but it would also make iteration and cross-platform support much harder at this stage.
The HTML/canvas approach definitely has tradeoffs. Large canvases, XY transforms, terminals, browser previews, editors, and agents all in one workspace can get expensive if handled naively. We’ve been working on viewport-based rendering, transform handling, and avoiding unnecessary re-renders, but it is still an ongoing performance challenge.
So yes, we accounted for it, but I would not claim it is “solved”. v1 is much better than the early builds, and we’re continuing to improve it.
npw55036 14 hours ago [-]
To be honest, I still prefer a finite canvas; an infinite canvas doesn't align with most people's intuition.
BlueBerry2001 13 hours ago [-]
That’s fair. Infinite canvas is not for everyone.
I think the important part is that it does not have to mean “everything everywhere forever”. Cate also has docking, tabs, splits, project-based layouts, and search, so you can use it more structured if you want. But yes, for some people a finite or stricter workspace model will feel better.
citbl 13 hours ago [-]
I appreciate the honesty of saying this is using electron.
I'm not sure what problem it actually solves or aims at solving other than being cool?
Visual orientation does matter in UX of the real world, video game worlds and to some degree operating systems, is this the goal?
BlueBerry2001 13 hours ago [-]
Fair question.
For me the problem is not “can I open windows?” Obviously every OS can do that. The problem is that once a project has terminals, dev server, browser preview, docs, AI chat, notes, multiple worktrees, etc., the surrounding workflow becomes the bottleneck.
Cate is trying to preserve that project context in one spatial workspace, so when you come back, the layout and tools are still where you left them. Visual orientation is part of it, but the bigger goal is reducing the constant switching/reconstructing of context.
9 hours ago [-]
justanotherunit 10 hours ago [-]
I don’t understand, why is this not a SHOW HN?
BlueBerry2001 6 hours ago [-]
Fair point. I probably should have submitted it as Show HN.
I posted it more as a progress/update thread because I was mainly looking for feedback from people with heavy terminal or multi-window workflows, but I agree that the format fits Show HN better.
ygouzerh 11 hours ago [-]
It looks great! I just wished my laptop screen was bigger, sounds better on a quite large monitor
BlueBerry2001 6 hours ago [-]
fair point
AbuAssar 12 hours ago [-]
> Cate is not a window manager replacement. Tiling/scrolling WMs (Hyprland, Niri, GlazeWM, KDE) are great if you mainly want to arrange OS windows. Cate is a spatial canvas around a single project's tools — closer to Figma's infinite canvas than to a WM.
BlueBerry2001 11 hours ago [-]
Yeah, that’s pretty much how I see it too.
Cate is not trying to compete with tiling/scolling WMs. Those are better if the main problem is arranging normal OS windows.
The goal here is more project-scoped: one spatial canvas where terminals, browser previews, editors, docs, notes, agents, git/worktrees, and saved layouts live together. More like a persistent workspace for a single project than a global desktop environment.
preezer 12 hours ago [-]
Hmmmmm I liked the idea. But I think, I maybe expected more a windowmanager.
BlueBerry2001 6 hours ago [-]
[flagged]
OtomotO 11 hours ago [-]
Spatial got me hooked, but then I saw the demo...
That's like the Antithesis of what
I want to do and why I am on niri...
The IDE has been "static" for most of the past ~20 years, with obvious improvements, but they were always incremental. The kind of exploration we see now is a bit more extreme, and I like it. It also seems like a lot of people are looking for alternatives, and I like some ideas. Even the funky ideas (I once saw a post comparing and proposing IDEs to follow RTS games UI) are interesting. Who knows what might stick.
Unlike Cate, the windows of the terminals, editor, browser, etc, each one was handled similarly like Niri tiling scrolling window manager, that way you can use the keyboard to move around, where you can group windows in a column or split them, have different sizes, is not quite where you have a free form, but an horizontal collection of windows that you can scroll.
I’m already using it as my primary terminal emulator and have recently just been adding LSP support to the code editor.
Is Cate's canvas per git-repo or can I add multiple?
I love looking through awesome-web-desktops. Most aren't infinite canvases but they are canvases, canvases of programs. There's fun stuff. UI paradigms being cooked up. I'll pitch in particular AetherOS, as being a neat web desktop that also is interestingly connected, networked, which is neat. https://github.com/syxanash/awesome-web-desktops https://bsky.app/profile/aetheros.computer
I do think we need to ask a little more "what next?". Taking Niri as a real desktop example, it's just so good, such simple but enjoyable new bones for a doing computing atop. So close to what was but so unique and nice. It intuitively connects me to the many many what ifs all around, makes me feel like there's such imminent possibility.
Especially today, who can make a UI that can be spoken well with, that is conversationally capable: that frontier feels barely explored. 9p is by far far far the most agentic desktop we have ever had, looked at this way. So beyond how it looks and works, how do computing surfaces express themselves?
LLM powered visual diagramming of the code as you work? The ability to edit the diagrams and have tje LLM apply that back to the code? Visualisation of test coverage over the UI you are working on? Allowing you to attach user submitted videos of bugs directly to tests in the code?
I don't know if any of that is a good idea, but I really hope a bunch of people try.
It's a weird skill but after seeing website, screenshot etc. I need only couple of seconds to make an opinion. I then look into history of project etc., though it rarely contradicts first impression.
I think I do this because I don't trust thus I don't want to use such projects. Not because vibe coded/vibe-code driven projects are inherently bad (they aren't). Because I think low self-investment translates to low ongoing self-interest.
Since all software is buggy to some degree, I'm certain I'll find a dealbreaker that will never be addressed, and risk is rarely worth it.
To use a comparison, have you ever picked up your phone to enter an TOTP / one time auth code and then accidentally found yourself texting a friend, or some other non-work activity. It’s particularly easy to get distracted if you have an open notification you didn’t see until you went to use that one time code on your phone.
Having a desktop app for your workspace helps hide Slack and other distracting items while context switching between different productivity apps.
Cate is an open source desktop workspace built around an infinite canvas. Instead of constantly switching between terminals, editors, browser previews, docs, and AI tools, you arrange everything spatially in one place.
Big improvements since the earlier posts:
docking, tabs, and splits detachable native OS windows git worktree support unified Cmd+K search much smoother rendering/performance on larger canvases AI provider + MCP integration Stack: Electron, React, Monaco, xterm.js/node-pty, Zustand.
Runs on macOS, Windows, and Linux. MIT licensed.
Would love feedback from people with heavy multi-window or terminal-based workflows.
8 days is a while?
I checked because I’ve had a similar idea for several years and wanted to see the earlier discussion on your shared Cate progress.
There’s nothing. You linked it 8 days ago on a brand new account and it died.
It’s definitely not dead though. Quite the opposite: the project is actively growing and improving. The first post didn’t get much traction, but we kept working on it, fixed a lot of rough edges, and v1 is in a much better state now.
I should have phrased that more clearly.
Right now Cate is a local desktop app because we wanted the first version to work closely with local projects, shells, files, node-pty/xterm, browser panels, Monaco, git worktrees, etc.
A self-hosted web version would need a different architecture: a backend that owns the PTY sessions, keeps them alive when the browser disconnects, handles auth/security, and syncs the canvas state to the client. Definitely possible, but a bigger shift than just “put the current app in the browser”.
Long term I think remote/headless workspaces and reconnectable sessions would make a lot of sense.
- I can't scale windows by grabbing the top edges like I can on the bottom/side edges.
- The command palette provides me with a list of open windows but selecting them doesn't do anything.
- A pinch to zoom gesture zooms in and out over unfocused panes but scrolls on focused ones. A keyboard modifier key I can hold that puts me into workspace pan/zoom mode regardless of where my cursor is would be great.
- It seems really erratic as to whether grabbing a pane and dragging will move it, scale it, or do nothing at all.
- The displayed cursor quite frequently has no correlation with what it's going to do.
- The mini map should really allow me to drag around my viewport on it rather than clicking and jumping to a specific place.
I really want to love this, its a great concept for working with complex projects but as I say right now its simply not there. Here's a few bonus things I'd love to see:
- The ability to rename terminal windows. Terminal 1,2,3,N is going to be unusable almost immediately.
- A jump to pane function (probably triggered via the command palette pane list) which allows me to select a specific terminal/editor/region/whatever and be jumped straight to it.
- Please add Kagi as a search engine option.
- As someone else has mentioned the real killer feature here would be the ability to run Cate with a remote backend, either accessed via a web browser or the Electron wrapper. I routinely use both VSCode devcontainers locally and remote machines over SSH and I'd love to be able to have a bunch of open sessions I can just jump back into.
I have a miro board as a notepad, I constantly add new stuff but at the same time its unmanageable.
Another example could be browser tabs, since there's no limit my current window holds approximately 60 open tabs which (which I dont use ofc) - this is the effect of chrome not having a native way to save stuff for later in a semantic way (you cannot search through bookmarks the same way you would search through google).
The success of this project will be defined by how well and easy users are able to retain the context (or content) of their canvas.
Navigation in default Obsidian is one of the weakest points imo
https://affine.pro/
The homepage explicitly calls out that "Cate is not a window manager replacement" yet as far as I can tell pretty much all its features are window management. And the ones that aren't would be better off living in their own dedicated apps anyway (or aren't going to replace people's preferred editors or terminals).
The infinite canvas idea sounds cool, and I'm not aware of a window manager that lets you zoom and pan around a massive "desktop", but it really does sound like the cool bits would be better implemented as an actual window manager. Then we can keep using our favourite IDEs, terminals, editors, etc. etc which is where the actual friction for change sits, and have the cool infinite canvas/docking/arranging stuff on top.
If you want their fancy windowing stuff, I think you also need to use their apps. Terminal, IDE, etc etc. Switching to a different terminal is friction, switching to a different IDE is a really big jump. My bet is most people aren't going to switch to a different IDE just to get different window management behaviours. And if the bundled IDE is brilliant, then you can't use that without this window management coming along for the ride too.
The differentiator for this project is the window management. Don't restrict that to just the re-implemented apps within the walled garden, and then you have the behaviour implemented in the right place.
[1] https://github.com/haystackeditor/haystack-editor
From a quick look, I agree there is overlap around the canvas editor idea. Cate is aiming a bit more at the broader project workspace layer: terminals, browser previews, editors, notes, agents, git/worktrees, docking/tabs/splits, and persistent layouts around a project.
But yes, fair callout. Appreciate the input.
Re-reading my comment made me realize it sounded condescending, where it was actually meant to emphasize that a canvas editor is a great idea! So I am very glad that there is development is this space.
Just felt the need to clarify this...
I see Cate also uses node-pty. I didn't know what psuedo terminals were before, it's cool stuff
Cate is a bit broader in scope: Electron desktop app, persistent project workspaces, node-pty/xterm terminals, browser panels, Monaco editors, docs, git/worktrees, docked tabs/splits, and now agent panels as well.
PTYs were a fun rabbit hole. The basic idea is simple, but making terminals feel native inside a canvas is where it gets tricky: lifecycle, resize behavior, restoring sessions, shell fallback, scrollback, performance, and not breaking when panels are moved/docked/detached.
Cool to see someone else exploring the terminal + canvas direction too. I’ll take a closer look at your repo.
One of the reasons why I did not go with an HTML based approach is because the XY translation gets really laggy with a couple dozen items.
Is that something you thought about and accounted for?
We chose Electron because the goal for v1 was to make Cate easy to try across macOS, Windows, and Linux without asking people to change their OS setup or use a specific window manager. A native implementation would probably give us more control and better performance in some areas, but it would also make iteration and cross-platform support much harder at this stage.
The HTML/canvas approach definitely has tradeoffs. Large canvases, XY transforms, terminals, browser previews, editors, and agents all in one workspace can get expensive if handled naively. We’ve been working on viewport-based rendering, transform handling, and avoiding unnecessary re-renders, but it is still an ongoing performance challenge.
So yes, we accounted for it, but I would not claim it is “solved”. v1 is much better than the early builds, and we’re continuing to improve it.
I'm not sure what problem it actually solves or aims at solving other than being cool?
Visual orientation does matter in UX of the real world, video game worlds and to some degree operating systems, is this the goal?
I posted it more as a progress/update thread because I was mainly looking for feedback from people with heavy terminal or multi-window workflows, but I agree that the format fits Show HN better.
Cate is not trying to compete with tiling/scolling WMs. Those are better if the main problem is arranging normal OS windows.
The goal here is more project-scoped: one spatial canvas where terminals, browser previews, editors, docs, notes, agents, git/worktrees, and saved layouts live together. More like a persistent workspace for a single project than a global desktop environment.
That's like the Antithesis of what I want to do and why I am on niri...
But to each their own I guess.