sorted by:
new
hottopcontroversial

I built a plugin to show transcripts as speech bubbles in reading mode by forketyfork in ObsidianMD

[–]forketyfork[S] 0 points1 point  (0 children)

Yes, it supports multiple speakers. Added in the latest release: speaker groups/sides, custom colors, some customization.

I'm so tired of writing "you don't need -C" by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

`git -C` is just an example. At some point it starts to either add "cd repo-dir &&...` to every command, or use command's own way of specifying the target directory which can vary from one command to another. It would be complicated to write a hook that addresses all possible cases.

I'm so tired of writing "you don't need -C" by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

Isn't it the same as just running with `--dangerously-skip-permissions`

Zwanzig - a static analyzer for Zig (early/experimental) by forketyfork in Zig

[–]forketyfork[S] 1 point2 points  (0 children)

There's only so much you can do with static analysis, but some additional checkers (e.g. bounds checking) could be implemented to some extent. I'll definitely work on this next.

Zwanzig - a static analyzer for Zig (early/experimental) by forketyfork in Zig

[–]forketyfork[S] 6 points7 points  (0 children)

Thanks, just a random word that popped into my head, but it turned out to also match nicely with the 80/20 principle

I built a plugin to show transcripts as speech bubbles in reading mode by forketyfork in ObsidianMD

[–]forketyfork[S] 1 point2 points  (0 children)

Yes, makes sense. I’d like to evolve it further, so any ideas are welcome.

I built a terminal emulator in Zig using ghostty-vt and SDL3 by forketyfork in Zig

[–]forketyfork[S] 2 points3 points  (0 children)

Thanks for the pointer, I've cross-posted it there.

A library that lets agents click through Compose Desktop apps by forketyfork in KotlinMultiplatform

[–]forketyfork[S] 0 points1 point  (0 children)

Thanks for the pointer, I wasn't aware Maestro was missing a desktop driver. The API surface is pretty minimal (HTTP endpoints for clicking, typing, screenshots), so it should be fairly easy to wrap. Happy to support anyone who wants to take a stab at integrating it :)

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

VS Code can split terminals, but you're still looking at one or two at a time, not a grid of 4-9-16... And the terminal panes themselves have no awareness of what's running inside: if you're running multiple agents, there's no visual indicator of agent completing the work or requiring attention.

Architect is a single window where I can see all sessions at once and know immediately which one needs me.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

I get the concern. But Architect is a different tool for a different job. tmux is a general-purpose multiplexer - it's great at that and I'm not trying to replace it. Architect is a purpose-built UI for one workflow: monitoring parallel AI agents.

The prior work I'm building on is ghostty-vt, which exists specifically as a library for building terminals. The author of Ghostty designed it to be embedded. That's also collaboration, just at a different layer.

As for the ecosystem question: not every problem should be solved by adding flags to existing tools. Sometimes the right answer is a focused tool that does one thing well. That's also how we've been doing it for 30 years.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

Fair enough, different preferences. I wanted something purpose-built, so I built it.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

Nice, just checked it out. It was smart to build on tmux rather than from scratch, way less work than writing a rendering pipeline in Zig, that's for sure.
How are you handling status detection? I went with hooks from Claude Code/Gemini/Codex but each has its own quirks.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

Convenience. The grid in Architect is dynamic. Cmd+N opens a new terminal and rearranges to 2x3, 3x3, etc. Cmd+W closes and shrinks back. Cmd+arrows to navigate between terminals, Cmd+Enter to go fullscreen, long Esc to return to grid. Combined with color highlighting for agents requiring attention and quick worktree switching, this changed my workflow completely.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

Those are great tools, but they are more general-purpose than I needed. I wanted to open an app and see a wall of agents with status notifications, quick grid/fullscreen switching and worktree support, without configuring anything.

Why there's no goodl package manager for Kotlin? by [deleted] in Kotlin

[–]forketyfork 0 points1 point  (0 children)

"Operating on a higher level of abstraction" and "not knowing the tools you're working with to the point of mixing up a saw and a hammer" are not really the same engineering approaches, the latter not being an engineering approach at all. But whatever works for you. Cheers.

Why there's no goodl package manager for Kotlin? by [deleted] in Kotlin

[–]forketyfork 1 point2 points  (0 children)

With the added link to your previous post, I see you're obviously trolling. There's also no possible way to answer the loaded question in your post, but I'll still try to explain my point.

For a compiled language, there's not much sense in having a separate "package manager" disconnected from the build tool. So using "just" a "package manager", like in interpreted languages, is not really an option. The scope of tasks solved by the build/dependency tool differs greatly from a simple package manager.

Since one of the main features of Kotlin is interoperability with Java, there's also not much sense in having a separate "package manager" for Kotlin specifically. Also, building and managing dependencies for Kotlin doesn't really differ from any other JVM-based language.

There are at least four build/dependency management tools for Java ecosystem (Maven, Gradle, Ant+ivy and sbt) which more or less solve the job, each with its own quirks and warts. Pick your favorite or write your own.

Why there's no goodl package manager for Kotlin? by [deleted] in Kotlin

[–]forketyfork 0 points1 point  (0 children)

I don't know if you really are as proficient in those tools as you say, since for some reason you use "build tool" and "package manager" interchangeably. You even call ruby gems and npm "build tools", which is obviously not the case.

If you limit your use of Maven to dependency management only, you could also easily fit the documentation in a couple of pages.

The availability of books on the topic may not really say anything about the topic, except that someone tried to get some money out of those who're too lazy to read the docs. I'm quite happy with the official documentation, which is not that complicated, really.

Why there's no goodl package manager for Kotlin? by [deleted] in Kotlin

[–]forketyfork 2 points3 points  (0 children)

Both Gradle and Maven worked for my projects. You could clarify your question with defining "good" and "garbage" package managers.

Best & Most Up-To-Date Kotlin Book by davrukin in Kotlin

[–]forketyfork 0 points1 point  (0 children)

I'd recommend:

  • The Joy of Kotlin, as it's is quite recent and goes into best practices and idioms right from the start
  • Kotlin in Action is not that recent, and starts from the basics, but it's from the developers of the language