Forem: Rain9

Are We Really Faster After AI Started Writing Our Code?

Rain9 — Sun, 12 Apr 2026 05:57:17 +0000

Recently, a question has been coming up more and more at work.

Everyone is using AI to write code, and on the surface, productivity seems to have taken off:

Pages are built faster
API layers are implemented faster
Even unfamiliar tech stacks can be “stitched together” quickly

But when it comes to deployment, things suddenly slow down:

Extra rounds of review
More test cases to write
Repeated validation of edge cases
Sometimes even rewriting parts of the core logic

And when you actually calculate the time spent, people start to wonder:

“Are we really faster than before?”

I’ve been struggling with this question myself.

A Subtle Illusion of Efficiency

The productivity gains from AI are real.

But the problem is:

It only accelerates one part of the process: writing code.

Software development has never been just about writing code.

A typical workflow looks like this:

Understanding requirements
Designing the solution
Writing code
Reviewing
Testing
Deploying
Maintaining

AI is currently best at step three:

“Writing code”

So what happens is:

Step three becomes extremely fast
But everything after that becomes heavier

Why Does It Feel Slower?

From my experience, there are three main reasons.

1. You Save Implementation Time, But Increase Cognitive Load

Before, coding was a synchronous process:

Think → Implement → Validate (all in one flow)

Now it looks like:

AI generates → You understand → Then validate

The issue is:

Understanding someone else’s code is harder than writing your own.

Even if that “someone” is AI.

2. Uncertainty Gets Amplified

Most of the time, AI-generated code is correct.

But the real problem is:

You don’t know when it’s wrong.

So naturally, you compensate by:

Writing more tests
Adding more validation
Introducing more safeguards

This is essentially risk hedging.

But the side effect is:

Heavier processes and slower flow.

3. We’re Using Old Processes with New Production Power

Many teams today are in this state:

Production method: AI generates code at scale
Process method: Traditional human-driven workflows

These two don’t match.

Before:

Write 200 lines/day → One round of review

Now:

Generate 2000 lines/day → Still one round of review

The result?

Reviews become superficial, or completely overwhelmed.

So, Are We Actually Faster?

There’s no absolute answer.

But here’s a more accurate way to think about it:

AI brings structural efficiency, not linear efficiency.

Where AI Clearly Speeds Things Up

Bootstrapping projects and scaffolding
Writing repetitive code
Rapid prototyping (PoC)
Exploring unfamiliar stacks

In these scenarios, the improvement is massive.

Where Things Get Slower (or Riskier)

Core business logic
Systems with complex edge cases
High concurrency or state-heavy flows
Long-term maintainable code

In these areas:

AI amplifies risk more than it improves speed.

The Real Problem Isn’t AI

At some point, I realized:

The problem isn’t AI.

It’s that:

We haven’t adapted our development workflow to AI yet.

We’re just plugging AI into an old system.

It’s like putting a race car on a narrow country road.

How Do We Actually Get Faster?

After some trial and error, I started adjusting how I work with AI.

Here are a few things that made a real difference.

1. Don’t Use AI Just to Write Code

This is the most important shift.

Most people use AI like this:

“Write code for me.”

But its real value is broader:

Analyzing problems
Identifying edge cases
Generating test cases
Even doing code reviews

I often ask things like:

What are the potential risks in this code?

Generate test cases that cover edge scenarios.

👉 The goal is:

Use AI to reduce uncertainty, not introduce it.

2. Break Down Large Generations into Small Steps

A key lesson:

Don’t generate large chunks of code in one go.

Because they are:

Hard to understand
Hard to review
Hard to debug

Instead:

One small feature at a time
Validate each step
Then move forward

It feels slower, but the overall flow becomes much more stable.

3. Build a Trust Layer

Not all code deserves the same level of trust.

I categorize things like this:

🟢 Low risk: UI, utilities → AI can handle freely
⚠️ Medium risk: business logic → must review
🔴 High risk: core logic → human-led

This prevents both blind trust and over-paranoia.

4. Shift Testing Earlier

Before:

Write code → then write tests

Now:

Define tests first → then let AI implement

Sometimes I directly ask:

Design test cases based on this requirement.

👉 This helps the generated code stay more constrained and reliable.

5. Accept the Trade-off: Less Execution, More Judgment

Many people expect AI to reduce workload.

But in reality:

It reduces manual work, and increases decision-making.

You now need to decide:

Is this logic sound?
Are edge cases covered?
Is it safe to deploy?

And that part cannot be outsourced.

A Deeper Shift

Before, writing code was about:

“How do I implement this?”

Now it’s more about:

“Can I trust this implementation?”

That’s a fundamental change.

Final Thoughts

So back to the original question:

Are we really faster after AI started writing our code?

My answer:

If you only use AI to generate code, not necessarily.
But if you adapt your workflow, then yes — significantly.

One last thought that stuck with me:

AI doesn’t automatically make you faster. It amplifies how you work.

Messy workflow → more chaos
Clear thinking → massive acceleration

So the real question isn’t about AI.

It’s about:

Are you in control of it?

I Got Tired of Boring Terminals — So I Built an AI That Walks on My Screen

Rain9 — Thu, 09 Apr 2026 05:14:57 +0000

🧠 It Started With a Simple Thought

Every day, I stare at the same thing:

A black terminal
A static AI chat window
Endless lines of code

Efficient? Yes.

Alive? Not even close.

At some point, a strange idea popped into my head:

What if my AI assistant wasn’t trapped in a box…

but actually lived on my desktop?

Not just responding to commands,

but walking around, idling, reminding me to rest—

like a tiny digital companion sharing my workspace.

That’s how CodeWalkers was born.

👾 Meet CodeWalkers

CodeWalkers is an open-source desktop AI companion built with:

Tauri v2
React
Rust

It’s part desktop pet, part AI terminal, and part productivity companion.

Instead of opening yet another window,

your AI becomes something you can see, drag, and live with.

🚶 Your AI... Now Has Legs

I designed two default characters:

Ethan
Luna

They don’t just sit there.

They:

walk along the bottom of your screen
stop, idle, and rest
quietly exist while you work

It’s subtle, but strangely comforting.

Like your code editor gained a soul.

And yes—you can replace them with anything you want.

Anime characters, pixel creatures, your own designs...

your desktop, your rules.

🖱️ The Magic Trick: Click-Through Transparency

One thing I absolutely didn’t want:

A floating pet that blocks your workflow 😅

So I implemented pixel-level click-through detection.

What this means:

Click the character → you can drag it
Click transparent areas → your click goes through it

No interference. No frustration.

It feels like the character truly belongs to your desktop.

💬 An AI Terminal That Feels… Alive

Click on your companion, and something interesting happens:

A real terminal appears. Not a fake UI.

Gemini CLI
Claude
Copilot

But here’s the twist:

When the AI responds…

💭 A speech bubble appears above your character

⌨️ Text streams out with a typewriter effect

🔊 Subtle keyboard sounds play in sync

It doesn’t feel like chatting with a tool anymore.

It feels like someone is thinking beside you.

⏰ It Even Takes Care of You

Let’s be honest:

We forget to rest. A lot.

So CodeWalkers quietly watches your time and nudges you when needed.

You can:

create custom states (Working, Eating, Sleeping...)
set interval reminders (every 45 min)
schedule exact times (like 18:40 = go home 🚪)

Each character has its own configuration.

And when the moment comes,

your companion raises a little bubble like:

“Hey… maybe drink some water?” 💧

Small detail. Big difference.

⚡ Why Tauri + Rust?

I love Electron. But I also fear it. 😄

Memory usage was a big concern.

So I chose:

Tauri v2 → lightweight, native-powered
Rust → performance and control

The result?

A desktop companion that can run all day

without turning your RAM into a crime scene.

🛠️ Tech Stack

Frontend: React + TypeScript + TailwindCSS + Zustand + shadcn/ui
Backend: Rust + Tauri v2
Terminal: portable-pty
Communication: Tauri IPC
Features:
- Transparent window
- System tray integration
- Real PTY streaming

🚀 Try It Yourself

GitHub: https://github.com/you-want/CodeWalkers

git clone https://github.com/you-want/CodeWalkers.git
cd CodeWalkers
pnpm install
pnpm tauri dev

🌱 Why I Open-Sourced It

Because this idea shouldn’t belong to just one person.

I’d love to see:

people creating their own characters
new interaction ideas
weird, creative experiments

Maybe someone turns it into a full game.
Maybe someone builds an AI companion with emotions.

Who knows?

💡 Final Thought

If this resonates with you,
consider giving it a ⭐ on GitHub or contributing!

Let’s make our desktops a little less lonely.

Tired of boring AI assistants? I built a "Desktop Pet" Copilot that wanders around your screen and writes code

Rain9 — Tue, 07 Apr 2026 09:40:49 +0000

Hey everyone.

I don't know if you feel the same way when coding, but while current AI coding assistants are incredibly useful, they sometimes feel a bit clunky to use.
You either have to constantly shift your focus back and forth between your code and the IDE sidebar, or context-switch to a browser to ask ChatGPT or Claude when you hit a general problem outside your specific project.

As a minimalist (read: lazy) developer, I kept thinking: How cool would it be if this AI could materialize on my screen like those old-school desktop pets (like Shimeji or BonziBuddy), wandering around and always on call?

Driven by this random thought over the holidays, I built an open-source desktop pet app — CodeWalkers.

🐶 What exactly is this?

Simply put, it's a cross-platform transparent desktop app built with Tauri V2.

It spawns a few pixel-art characters on your screen. These little guys don't just aimlessly wander over your code editor or browser—more importantly, they come with an "AI brain".

When you run into a coding issue, just click on a character, and a terminal panel pops up right there in place.
Currently, I've wired them up to real backend brains: GitHub Copilot CLI and Gemini CLI. You can directly ask them how to write a regex, configure Nginx, or even explain a piece of code right in the popup panel.

Even better, while it's "thinking" (calling the LLM API), a classic RPG-style thinking bubble pops up over its head. This turns the normally boring CLI loading spinners into a visual, interactive pet experience.

🛠️ How does it work? (Let's talk tech)

To bring this slightly goofy but cool idea to life, I used the Tauri v2 + React + TypeScript stack.

Even though it just looks like a little guy walking around the screen, I actually hit quite a few massive roadblocks during development. If you're interested in building desktop apps with Tauri, here are some pitfalls to avoid:

1. Phantom Clicks: The Transparent Window Passthrough Problem

To build a desktop pet, the first step is to make the app window globally transparent (transparent: true) and remove the OS window shadows and borders.
But this introduces a paradox: How do you make the mouse click the character, without blocking clicks to the code editor behind it?
Tauri provides the set_ignore_cursor_events API to control mouse passthrough. However, on macOS, if you have a transparent window, clicking a fully transparent pixel (alpha=0) automatically passes the click through to the desktop app underneath.
My workaround: I combined React's requestAnimationFrame with pixel-level hit-testing, and applied an extremely faint background color (rgba(255, 255, 255, 0.01)) to the transparent wrapper. This essentially tricks the macOS hit-testing system, achieving perfect precision without messing up the UI.

2. Stuffing a Real CLI into a Pet's Brain: PTY & Environment Variables

I wanted the pet to actually do work, not just be a dumb chatbox. So, I hijacked std::process::Command in the Rust backend.
To get a highly interactive CLI tool like Copilot running, I had to handle complex separation of standard output (stdout) and standard error (stderr). Through stream parsing, I intercepted all the ANSI escape codes and progress spinner characters (like ⠋) spat out by the CLI, converting them in real-time into the thinking bubble UI above the character.
Additionally, to prevent environment variable pollution, I built a dynamic injection mechanism using a local .codewalkers.env file, allowing you to securely feed it API tokens locally.

3. High FPS Animation Without Lag

Many overlay apps built with Electron or Tauri tend to hog the CPU the moment animations are involved.
In this project, I avoided putting the character's coordinate positions (x, y) into React State (which would trigger insane amounts of re-rendering). Instead, I manipulated the DOM's transform property directly via ref, coupled with requestAnimationFrame. This brute-forced a web animation to run with native 60 FPS smoothness.

🎨 Customization and Skins

Knowing everyone has different tastes in virtual pets, CodeWalkers fully supports custom skins.
You just need to drop your favorite GIF into the designated directory, tweak a few Sprite configuration parameters, and you can raise Hatsune Miku, Mario, or your own custom pixel art right on your desktop.

The project has already achieved a complete loop: from drag-and-drop movement and click interactions to terminal conversations.

🚀 Open Source & Contributing

CodeWalkers is now completely open-source. The codebase is clean, free of bloated dependencies, and I've already set up CI/CD and decent test coverage.

GitHub Repo: https://github.com/you-want/CodeWalkers

If you:

Think this is a fun idea
Want your own personal AI desktop assistant
Want to learn real-world Tauri V2 development (especially transparent windows, multi-process IPC, and PTY interactions)

Feel free to drop a Star to support the project! 🌟

I also highly welcome PRs! Whether it's adding new character skins, or integrating more LLM CLIs (like Claude, Ollama, or even a locally running DeepSeek)—I'm all for it.

Let's say goodbye to boring terminal boxes and add a little cyber-vitality to our screens!

react

Rain9 — Wed, 11 Mar 2026 13:48:50 +0000

AI

Rain9 — Sun, 01 Mar 2026 13:18:12 +0000

Building a Hugo + Tailwind technical blog from scratch: Taking INFINI Labs Blog as an example

Rain9 — Sat, 20 Dec 2025 06:40:40 +0000

Project Overview

This blog is a typical static-site blog project: content is written in Markdown, then Hugo (a Go-based static site generator) renders it into HTML during the build phase, and TailwindCSS + PostCSS bundle the final CSS during the build phase as well. After deployment, there is no backend required—any static hosting (GitHub Pages / Netlify / Vercel / S3+CDN) can serve it.

Two key aspects of this project are especially worth noting:

It uses Hugo Modules to reuse theme capabilities (such as image processing, PWA, SEO, and UI components), so CI must install Go (to fetch/manage module dependencies).
The homepage additionally generates a search index index.json, and the pages inject a prebuilt search UI (/static/assets/*), enabling offline/local search in the browser.

The rest of this article explains both “how to set it up” and “how it works” in detail.

1. Directory Structure: Where Do Content, Theme, Config, and Assets Live?

You can think of this repository as four layers:

1) Content Layer: `content/`

content/english/posts/: blog posts (Markdown + front matter)
content/english/authors/: author pages (Markdown + front matter)

Each post starts with front matter (YAML/TOML/JSON are all supported; this repo uses YAML). Typical fields include:

title / description: used for page title and SEO
date: publish time (affects ordering and display)
categories / tags: used for category and tag pages
image: cover image
author: author name (linked to the corresponding author page)

Templates read these fields. For example, themes/hugoplate/layouts/posts/single.html displays the cover image, author, categories, publish date, the main content, and the table of contents (TOC).

2) Configuration Layer: `hugo.toml` + `config/_default/*`

Hugo supports splitting configuration under the config/ directory. This project uses:

Root config: hugo.toml
- theme = "hugoplate"
- outputs.home includes JSON to generate public/index.json
- build.buildStats.enable = true for accurate Tailwind scanning (explained later)
Language config: config/_default/languages.toml
- English language with contentDir = "content/english"
Site parameters: config/_default/params.toml
- logo / favicon, theme colors, announcement bar, cookie banner, sidebar widgets, etc.
Hugo Modules: config/_default/module.toml
- Imports modules like github.com/gethugothemes/hugo-modules/images, pwa, seo-tools, etc. (this is where the Go dependency comes from)

3) Theme Layer: `themes/hugoplate/`

The theme defines the page structure and Hugo Pipes:

themes/hugoplate/layouts/_default/baseof.html: base layout skeleton
themes/hugoplate/layouts/index.html: homepage list
themes/hugoplate/layouts/posts/single.html: post detail page
themes/hugoplate/layouts/index.json: template that generates the JSON search index (important)

Note: you’ll see {{ partial "image" ... }} in templates, but there is no partials/image.html inside the theme directory. That partial comes from Hugo Modules (the hugo-modules/images module imported in config/_default/module.toml). This is a common pattern: “theme + modular capabilities.”

4) Asset Layer: `assets/` vs `static/`

These two directories behave differently in Hugo:

assets/: resources processed by Hugo Pipes (compile, fingerprint, minify, etc.)
- Images live under assets/images/... and are emitted to public/images/... during build
- Styles/scripts source files also live under themes/hugoplate/assets/* and are bundled via Hugo Pipes
static/: copied to public/ as-is
- This project includes static/assets/index-*.css/js and pizza_wasm_bg-*.wasm
- baseof.html hardcodes imports for /assets/index-*.css and /assets/index-*.js

2. Build Pipeline: What Happens From Markdown to Final HTML/CSS/JS?

1) Build entry points: `package.json` scripts

The key scripts are:

dev: hugo server
build: hugo --gc --minify --templateMetrics --templateMetricsHints --forceSyncStatic

So Hugo drives the whole build. Node is mainly here for PostCSS/Tailwind.

Also, CI/hosting often runs this before build:

project-setup: node ./scripts/projectSetup.js

This script comes from the Hugoplate template project and is used to “move” the exampleSite/ layout into the real project layout. Since this repository already has a themes/ directory, the script typically prints Project already setup (i.e., it does nothing and is safe to keep in CI).

2) Hugo Modules: Why does CI install Go?

Because config/_default/module.toml uses Hugo Modules, such as:

github.com/gethugothemes/hugo-modules/images
github.com/gethugothemes/hugo-modules/pwa
github.com/gethugothemes/hugo-modules/seo-tools/basic-seo
github.com/hugomods/mermaid
etc.

These modules are fetched during build and participate in rendering. The repo’s go.mod locks module versions (you can treat it as the dependency manifest for Hugo Modules).

So the division of responsibilities is:

Hugo renders the site
Go pulls and manages Hugo Module dependencies

That’s why CI installs both Hugo and Go (see netlify.toml and .github/workflows/hugo.yml).

3) How does Tailwind generate only the CSS you actually use?

Two configs are key:

hugo.toml enables build stats: [build.buildStats] enable = true
tailwind.config.js uses: content: ["./hugo_stats.json"]

Hugo emits hugo_stats.json while rendering templates, recording the classes/tokens used by the generated HTML. Tailwind reads this file and can very accurately generate only the required utility classes, avoiding scanning the entire template/content tree (which can lead to false positives and a much larger CSS bundle).

In addition, hugo.toml includes a module mount:

Mounts hugo_stats.json into assets/watching/hugo_stats.json
Combined with cache-busting config so CSS rebuilds trigger correctly

This is a well-established integration approach in Hugoplate-based setups.

4) How are CSS/JS bundled, minified, and fingerprinted?

In themes/hugoplate/layouts/partials/essentials/style.html, you can see the Hugo Pipes flow:

Collect plugin CSS (from hugo.toml params.plugins.css)
Compile scss/main.scss (requires Hugo extended)
resources.Concat to merge
css.PostCSS to run PostCSS (Tailwind + autoprefixer)
In production: minify | fingerprint | resources.PostProcess
Output <link href="...style.<hash>.css" integrity="...">

JS is handled similarly in themes/hugoplate/layouts/partials/essentials/script.html.

This also explains two important runtime facts:

After deployment, the site is pure static files (HTML/CSS/JS/images), with no runtime compilation.
Fingerprinting stabilizes caching: when content changes, the asset URL changes, so browsers/CDNs won’t serve stale assets.

3. Search: How Do `index.json` and `/static/assets/*` Work Together?

1) Where does the index come from?

hugo.toml sets outputs.home = ["HTML", "RSS", "WebAppManifest", "JSON"] and configures JSON output with baseName = "index". So the build generates:

public/index.json

The template that creates it is:

themes/hugoplate/layouts/index.json

It iterates over site pages and packs fields such as title, URL, tags, category, description, and the plain-text content into a JSON array.

This is a great data source for client-side search, especially on static sites.

2) Where does the search UI come from?

themes/hugoplate/layouts/_default/baseof.html hardcodes:

<link rel="stylesheet" href="/assets/index-*.css">
<script type="module" src="/assets/index-*.js"></script>

These files live in static/assets/ and are copied to public/assets/ by Hugo, so browsers can request them directly after deployment.

At runtime (when users open the site):

The browser loads the static page
It loads the search UI JS/CSS
The search UI fetches index.json (and potentially WASM assets) and builds an index in the browser
Searches run locally in the browser—no backend API required

This is a common approach to “enhance” static sites: generate data at build time, consume it with front-end code at runtime.

4. Building a Similar Project From Scratch (Minimum Viable Steps)

Here is a practical checklist if you want to replicate this repository’s approach.

1) Prepare the toolchain

Hugo extended (this project requires >= 0.139.2, see config/_default/module.toml)
Go (CI uses 1.23.3 for Hugo Modules)
Node (for PostCSS/Tailwind; CI uses Node 20, but a common LTS should work locally)

2) Install dependencies and start development

This repo declares pnpm, but the scripts are compatible with npm/yarn as well.

pnpm install
pnpm dev
# or: npm install && npm run dev

This starts the Hugo dev server.

3) Add a new post

Create a Markdown file under content/english/posts/YYYY/, for example:

---
title: "My First Post"
description: "A short summary"
date: "2025-12-20T09:00:00+08:00"
categories: ["Engineering"]
tags: ["Hugo"]
image: "/images/posts/2025/some-folder/cover.jpg"
author: "Rain9"
lang: "en"
category: "Technology"
subcategory: "Engineering"
draft: true
---

# Hello

Write something here.

It’s recommended to put images under assets/images/posts/... and reference them as /images/posts/.... After building, they will be emitted under public/images/posts/....

4) Build for production

pnpm build

The output directory is public/ (see netlify.toml: publish = "public").

5. Deployment & CI/CD: How Netlify / GitHub Pages / Vercel Build It

This repository supports multiple hosting platforms:

1) Netlify

netlify.toml:

build command: yarn project-setup; yarn build
publish: public
env: HUGO_VERSION=0.139.2, GO_VERSION=1.23.3

2) GitHub Pages (GitHub Actions)

.github/workflows/hugo.yml does:

checkout
install Node
download Hugo extended
install Go
npm run project-setup
npm install
npm run build
upload public as Pages artifact and deploy

3) Vercel

vercel-build.sh runs on the build machine:

install Go
install Hugo extended
npm run project-setup
npm install
npm run build

All platforms do the same thing in the end: provision the build toolchain (Hugo + Go + Node) and produce public/.

Wrap-up: The Boundary Between Build-Time and Run-Time

The core idea of a Hugo-based blog is simple:

Build-time: Hugo compiles content, templates, modules, and assets into static files (and also performs minification, fingerprinting, and index generation).
Run-time: the CDN/static server only serves files; the browser runs a small amount of front-end JS (like the search UI). No backend API is required.

Once you understand this boundary, it becomes natural to extend the site: when adding new features, first ask “can we generate the data at build time?” and then “can the browser consume it at run time?”

Rain9 — Tue, 15 Jul 2025 00:00:53 +0000

useEffect

Rain9 — Fri, 14 Mar 2025 00:48:54 +0000

Tauri (9) - Implementing automatic startup of desktop applications

Rain9 — Mon, 27 Jan 2025 07:43:10 +0000

Introduction

In many desktop applications, implementing the "launch at startup" feature is a common requirement, especially when the app needs to automatically start and stay running as soon as the operating system boots. This article will introduce how to implement the startup launch feature for desktop applications using Tauri.

Implementation Principle

Tauri provides the tauri-plugin-autostart plugin, allowing developers to easily configure applications to launch at startup. This plugin supports multiple operating systems (Windows, macOS, Linux) and provides simple APIs to manage the auto-start functionality.

Installing the Plugin

Install the Plugin: To enable the startup launch feature, you need to install the tauri-plugin-autostart plugin in your Tauri project.

Open the terminal in the project root directory and run the following command:
```
cargo tauri plugin add tauri-plugin-autostart
```

Configure Permissions: After installing the plugin, update the configuration in the src-tauri/capabilities/default.json file.

Add the following to the permissions section in the src-tauri/capabilities/default.json file:

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "default",
  "description": "Capability for the main window",
  "windows": ["main", "chat", "settings"],
  "permissions": [
    "autostart:allow-enable",
    "autostart:allow-disable",
    "autostart:allow-is-enabled"
  ]
}

Rust Code Implementation

Implement the core functionality in src-tauri/src/autostart.rs:

use std::{fs::create_dir, io::Read};
use tauri::{Manager, Runtime};
use tauri_plugin_autostart::ManagerExt;

pub fn enable_autostart(app: &mut tauri::App) {
    use tauri_plugin_autostart::MacosLauncher;

    app.handle()
        .plugin(tauri_plugin_autostart::init(
            MacosLauncher::AppleScript,
            None,
        ))
        .unwrap();

    let autostart_manager = app.autolaunch();

    match (
        autostart_manager.is_enabled(),
        current_autostart(app.app_handle()),
    ) {
        (Ok(false), Ok(true)) => match autostart_manager.enable() {
            Ok(_) => println!("Autostart enabled successfully."),
            Err(err) => eprintln!("Failed to enable autostart: {}", err),
        },
        (Ok(true), Ok(false)) => match autostart_manager.disable() {
            Ok(_) => println!("Autostart disabled successfully."),
            Err(err) => eprintln!("Failed to disable autostart: {}", err),
        },
        _ => (),
    }
}

fn current_autostart<R: Runtime>(app: &tauri::AppHandle<R>) -> Result<bool, String> {
    use std::fs::File;

    let path = app.path().app_config_dir().unwrap();
    let mut old_value = true;

    if path.exists() {
        let file_path = path.join("autostart.txt");
        if file_path.exists() {
            let mut file = File::open(file_path).unwrap();
            let mut data = String::new();
            if let Ok(_) = file.read_to_string(&mut data) {
                if !data.is_empty() {
                    old_value = data.parse().unwrap_or(true);
                }
            }
        }
    };

    Ok(old_value)
}

#[tauri::command]
pub fn change_autostart<R: Runtime>(app: tauri::AppHandle<R>, open: bool) -> Result<(), String> {
    use std::fs::File;
    use std::io::Write;

    let autostart_manager = app.autolaunch();

    let change = |open: bool| -> Result<(), String> {
        let mut open_str = String::from("");
        if open {
            autostart_manager
                .enable()
                .map_err(|_| "enable autostart failed".to_owned())?;
            open_str = "true".to_owned();
        } else {
            autostart_manager
                .disable()
                .map_err(|_| "disable autostart failed".to_owned())?;
            open_str = "false".to_owned();
        }

        let path = app
            .path()
            .app_config_dir()
            .map_err(|_| "not found app config directory".to_owned())?;
        if !path.exists() {
            create_dir(&path).map_err(|_| "creating app config directory failed".to_owned())?;
        }

        let file_path = path.join("autostart.txt");
        let mut file = File::create(file_path).unwrap();
        file.write_all(open_str.as_bytes()).unwrap();

        Ok(())
    };

    match (autostart_manager.is_enabled().unwrap(), open) {
        (false, true) => change(true),
        (true, false) => change(false),
        _ => Err("no change".to_owned()),
    }
}

mod autostart;

use autostart::{change_autostart, enable_autostart};
use tauri_plugin_autostart::MacosLauncher;

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    let mut ctx = tauri::generate_context!();

    tauri::Builder::default()
        .plugin(tauri_plugin_autostart::init(
            MacosLauncher::AppleScript,
            None,
        ))
        .invoke_handler(tauri::generate_handler![change_autostart])
        .setup(|app| {
            enable_autostart(app);
            Ok(())
        })
        .run(ctx)
        .expect("error while running tauri application");
}

Frontend: Configuring Auto-Start

In the frontend, call the backend commands to toggle the startup launch status:

import { isTauri, invoke } from "@tauri-apps/api/core";
import { isEnabled } from "@tauri-apps/plugin-autostart";

const [launchAtLogin, setLaunchAtLogin] = useState(true);

useEffect(() => {
  const fetchAutoStartStatus = async () => {
    if (isTauri()) {
      try {
        const status = await isEnabled();
        setLaunchAtLogin(status);
      } catch (error) {
        console.error("Failed to fetch autostart status:", error);
      }
    }
  };

  fetchAutoStartStatus();
}, []);

const enableAutoStart = async () => {
  if (isTauri()) {
    try {
      invoke("change_autostart", { open: true });
    } catch (error) {
      console.error("Failed to enable autostart:", error);
    }
  }
  setLaunchAtLogin(true);
};

const disableAutoStart = async () => {
  if (isTauri()) {
    try {
      invoke("change_autostart", { open: false });
    } catch (error) {
      console.error("Failed to disable autostart:", error);
    }
  }
  setLaunchAtLogin(false);
};

Conclusion

With the tauri-plugin-autostart plugin, implementing the "launch at startup" feature for Tauri apps becomes straightforward. The plugin supports multiple platforms, simplifying the cross-platform development of this functionality. By configuring and using Tauri's API, you can easily manage your app's auto-start status.

I hope this article helps you implement startup launch functionality for your Tauri desktop app. Feel free to discuss if you have any questions!

Open Source

Recently, I’ve been working on a project based on Tauri called Coco. It’s open source and under continuous improvement. I’d love your support—please give the project a free star 🌟!

This is my first Tauri project, and I’ve been learning while exploring. I look forward to connecting with like-minded individuals to share experiences and grow together!

Official website: coco.rs/
Frontend repo: github.com/infinilabs/coco-app
Backend repo: github.com/infinilabs/coco-server

Thank you for your support and attention!

tauri

Rain9 — Sun, 26 Jan 2025 01:06:51 +0000

Tauri (1) — A desktop application development solution more suitable for web developers ✅

Rain9 — Sat, 25 Jan 2025 14:24:23 +0000

Background

We recently decided to develop an open-source desktop application (keeping it a secret for now, but stay tuned! Follow to avoid missing out!), and chose Tauri as our tech stack. It's a lesser-known option for most people, but for those interested, let's dive deeper!

Introduction to Tauri

Official Website: https://tauri.app/ (v2.0)
GitHub: https://github.com/tauri-apps/tauri (84k Stars)

Official Description: Create small, fast, secure, and cross-platform applications

Simple Understanding

Tauri is a cross-platform desktop application framework that allows developers to use familiar web technologies (like HTML, CSS, JS, and frameworks such as Vue.js, Svelte, React, SolidJS, Angular, Preact, etc.) to easily build desktop applications.

For us web developers looking to delve into desktop application development, Tauri is a great choice, without the steep learning curve. Web technologies have become one of the most powerful UI tools, running seamlessly on platforms with web browsers. With Tauri, we can design the UI exactly as we would on the web, meaning we can continue using our familiar web development skills to create amazing and user-friendly interfaces.

In some cases, desktop applications perform better than web apps. One of the key reasons for choosing desktop applications is that web apps are often limited by the native APIs available within a browser and can't interact with the operating system in the way desktop apps can (e.g., we can't access the file system or read clipboard data with web apps). Desktop applications can interact more deeply with the operating system's APIs and can be optimized for performance with more efficient languages (e.g., Rust). So, if a framework can combine the flexibility of a web UI with full access to native APIs, it is the perfect choice.

Tauri combines two major ecosystems and provides access to native APIs, creating a more complete developer experience.

The architecture of Tauri consists of two core components:

The frontend, built with Web technologies
The backend, developed using the Rust programming language, called Tauri Core.

The frontend allows us to use the Web technologies we are comfortable with (like React and Vue) to create flexible and visually appealing UIs, while the Rust backend opens the door to native APIs through inter-process communication (e.g., clipboard access or file system operations). Thanks to Rust’s performance, even computationally intensive tasks can be efficiently and smoothly handled.

This is why we believe Tauri is the ideal choice for building cross-platform desktop apps based on web technologies (our tech stack decision).

VS Electron

Introduction to Electron

Electron Website: https://www.electronjs.org/ (v33.0)
GitHub: https://github.com/electron/electron (114k Stars)

At this point, we must mention Electron, which might be the most popular cross-platform framework today. The iteration of its versions and the number of stars it has accumulated speaks for itself. Electron has proven its value by being the foundation of many well-known applications. The Electron apps directory is a showcase of its wide usage and powerful functionality, with a community that highly acknowledges Electron's achievements.

Before diving into any technical details, I think it’s important to compare Electron with other frameworks, so we can better assess which framework best fits our needs.

State of JavaScript User Data Comparison

To make a fair comparison, let’s take a look at the State of JavaScript survey data. It covers various aspects such as usage, awareness, retention, enthusiasm, etc.

Survey data link: https://2023.stateofjs.com/zh-Hans/libraries/mobile_desktop/

Usage

Awareness

Interest

Retention

Enthusiasm

Technical Comparison

Regarding the technical comparison, I’m still getting started, so I can’t offer too much advice, but many people online have provided comparison results. Let’s take a look.

Here’s a comparison table between ElectronJS and Tauri, showing their differences across multiple dimensions:

Feature	ElectronJS	Tauri
Framework Size	Large application size, usually over 100MB	Much smaller application size, typically under 10MB
Memory Usage	High memory usage, each app instance requires more memory	Lower memory usage, uses fewer resources
Tech Stack	Based on Chromium and Node.js (bundles the entire browser runtime)	Based on WebView and Rust (no need to bundle the entire browser)
Performance	Lower performance due to bundling Chromium	Higher performance with native WebView component
API Access	System APIs available via Node.js	Rust backend provides easy access to native OS APIs
Security	Must be careful about communication between Node.js and web content	More secure by default, with strict security policies
Packaging & Publishing	Requires electron-builder or electron-forge for packaging	Built-in packaging tools (AppImage, DMG, EXE), no external dependencies
Supported Languages	JavaScript, TypeScript	JavaScript, TypeScript (frontend) and Rust (backend)
Ecosystem	Rich community and plugin ecosystem, many templates and tools	Growing community, stable official templates
Developer Experience	Strong documentation and community support, easy to start	Lightweight solution, documentation is complete but learning Rust may have a steeper curve
Cross-Platform Support	Supports Windows, macOS, Linux	Supports Windows, macOS, Linux, with easier optimizations for size and performance
Debugging Tools	Supports Chrome DevTools, easy to develop and debug	Supports DevTools, similar frontend debugging, but Rust debugging requires additional tools
Update Mechanism	Requires manual update configuration, like electron-updater	Built-in auto-update feature, simplified update process
Project Initialization	- Requires manual creation of npm projects, install Electron libraries.	- Provides a built-in CLI tool to quickly generate projects.
	- Start from scratch, configure project structure manually.	- Uses official templates to automatically configure the project structure, reducing manual setup.
Official Template Support	- Lacks official templates, relies on community-maintained boilerplates.	- Offers multiple official templates, supporting frameworks like React, Vue, Svelte, etc.

Summary of Major Differences:

Complexity: Tauri has built-in tools, official templates, and simplified configuration files; Electron requires more tools and dependencies, with fewer official templates.
Size & Performance: Tauri is much lighter and performs better, making it ideal for resource-sensitive scenarios; Electron is heavier but has a more mature ecosystem.
System API Access: Tauri provides more direct access to native OS APIs, ideal for apps that require native functionality; Electron relies on Node.js, needing extra configuration for system resource access.
Packaging & Publishing: Tauri has more efficient and simple packaging, particularly when generating lightweight apps.

References for Comparison:

Conclusion

With the rapid development of Web technologies, developers are no longer limited to traditional native programming languages when building desktop apps. Tauri, as a lightweight, cross-platform desktop application framework, perfectly combines the flexibility of web development with the power of desktop apps. It opens the door to desktop development for developers familiar with front-end technologies without the steep learning curve. In this article, we explored why Tauri is an ideal choice for web developers, as it not only leverages existing web skills but also enables seamless access to native APIs, making it easier to build outstanding desktop apps.

Open Source

Recently, I’ve been working on a project based on Tauri called Coco. It’s open source and under continuous improvement. I’d love your support—please give the project a free star 🌟!

This is my first Tauri project, and I’ve been learning while exploring. I look forward to connecting with like-minded individuals to share experiences and grow together!

Official website: coco.rs/
Frontend repo: github.com/infinilabs/coco-app
Backend repo: github.com/infinilabs/coco-server

Thank you for your support and attention!

Tauri (8) - Implementing global shortcut key function

Rain9 — Sat, 25 Jan 2025 13:52:37 +0000

Introduction

In modern desktop applications, shortcuts are an essential tool for enhancing user experience and productivity. Many applications allow users to perform specific actions through shortcuts. As a cross-platform desktop application framework, Tauri provides rich functionality to support global shortcuts.

This article introduces how to implement global shortcut functionality in Tauri, guiding you step-by-step to create a desktop application that supports global shortcuts.

Installing Dependencies

To get started, install the necessary dependencies:

pnpm tauri add global-shortcut

pnpm tauri add store

After installation, you can use @tauri-apps/plugin-global-shortcut in the frontend as follows:

import { register } from '@tauri-apps/plugin-global-shortcut';
// When using `"withGlobalTauri": true`, you may use:
// const { register } = window.__TAURI__.globalShortcut;

await register('CommandOrControl+Shift+C', () => {
  console.log('Shortcut triggered');
});

On the Rust side, the tauri-plugin-global-shortcut plugin will also be available for use:

pub fn run() {
    tauri::Builder::default()
        .setup(|app| {
            #[cfg(desktop)]
            {
                use tauri_plugin_global_shortcut::{Code, GlobalShortcutExt, Modifiers, Shortcut, ShortcutState};

                let ctrl_n_shortcut = Shortcut::new(Some(Modifiers::CONTROL), Code::KeyN);
                app.handle().plugin(
                    tauri_plugin_global_shortcut::Builder::new().with_handler(move |_app, shortcut, event| {
                        println!("{:?}", shortcut);
                        if shortcut == &ctrl_n_shortcut {
                            match event.state() {
                              ShortcutState::Pressed => {
                                println!("Ctrl-N Pressed!");
                              }
                              ShortcutState::Released => {
                                println!("Ctrl-N Released!");
                              }
                            }
                        }
                    })
                    .build(),
                )?;

                app.global_shortcut().register(ctrl_n_shortcut)?;
            }
            Ok(())
        })
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Permission Configuration

In the src-tauri/capabilities/default.json file, add the following configuration:

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "main-capability",
  "description": "Capability for the main window",
  "windows": ["main"],
  "permissions": [
    "global-shortcut:allow-is-registered",
    "global-shortcut:allow-register",
    "global-shortcut:allow-unregister",
    "global-shortcut:allow-unregister-all"
  ]
}

Implement Global Shortcuts

Create a shortcut.rs file in the src-tauri/src directory:

use tauri::App;
use tauri::AppHandle;
use tauri::Manager;
use tauri::Runtime;
use tauri_plugin_global_shortcut::GlobalShortcutExt;
use tauri_plugin_global_shortcut::Shortcut;
use tauri_plugin_global_shortcut::ShortcutState;
use tauri_plugin_store::JsonValue;
use tauri_plugin_store::StoreExt;

/// Name of the Tauri storage
const COCO_TAURI_STORE: &str = "coco_tauri_store";

/// Key for storing global shortcuts
const COCO_GLOBAL_SHORTCUT: &str = "coco_global_shortcut";

/// Default shortcut for macOS
#[cfg(target_os = "macos")]
const DEFAULT_SHORTCUT: &str = "command+shift+space";

/// Default shortcut for Windows and Linux
#[cfg(any(target_os = "windows", target_os = "linux"))]
const DEFAULT_SHORTCUT: &str = "ctrl+shift+space";

/// Set shortcut during application startup
pub fn enable_shortcut(app: &App) {
    let store = app
        .store(COCO_TAURI_STORE)
        .expect("Creating the store should not fail");

    // Use stored shortcut if it exists
    if let Some(stored_shortcut) = store.get(COCO_GLOBAL_SHORTCUT) {
        let stored_shortcut_str = match stored_shortcut {
            JsonValue::String(str) => str,
            unexpected_type => panic!(
                "COCO shortcuts should be stored as strings, found type: {} ",
                unexpected_type
            ),
        };
        let stored_shortcut = stored_shortcut_str
            .parse::<Shortcut>()
            .expect("Stored shortcut string should be valid");
        _register_shortcut_upon_start(app, stored_shortcut); // Register stored shortcut
    } else {
        // Use default shortcut if none is stored
        store.set(
            COCO_GLOBAL_SHORTCUT,
            JsonValue::String(DEFAULT_SHORTCUT.to_string()),
        );
        let default_shortcut = DEFAULT_SHORTCUT
            .parse::<Shortcut>()
            .expect("Default shortcut should be valid");
        _register_shortcut_upon_start(app, default_shortcut); // Register default shortcut
    }
}

/// Get the current stored shortcut as a string
#[tauri::command]
pub fn get_current_shortcut<R: Runtime>(app: AppHandle<R>) -> Result<String, String> {
    let shortcut = _get_shortcut(&app);
    Ok(shortcut)
}

/// Unregister the current shortcut in Tauri
#[tauri::command]
pub fn unregister_shortcut<R: Runtime>(app: AppHandle<R>) {
    let shortcut_str = _get_shortcut(&app);
    let shortcut = shortcut_str
        .parse::<Shortcut>()
        .expect("Stored shortcut string should be valid");

    // Unregister the shortcut
    app.global_shortcut()
        .unregister(shortcut)
        .expect("Failed to unregister shortcut")
}

/// Change the global shortcut
#[tauri::command]
pub fn change_shortcut<R: Runtime>(
    app: AppHandle<R>,
    _window: tauri::Window<R>,
    key: String,
) -> Result<(), String> {
    println!("Key: {}", key);
    let shortcut = match key.parse::<Shortcut>() {
        Ok(shortcut) => shortcut,
        Err(_) => return Err(format!("Invalid shortcut {}", key)),
    };

    // Store the new shortcut
    let store = app
        .get_store(COCO_TAURI_STORE)
        .expect("Store should already be loaded or created");
    store.set(COCO_GLOBAL_SHORTCUT, JsonValue::String(key));

    // Register the new shortcut
    _register_shortcut(&app, shortcut);

    Ok(())
}

/// Helper function to register a shortcut, primarily for updating shortcuts
fn _register_shortcut<R: Runtime>(app: &AppHandle<R>, shortcut: Shortcut) {
    let main_window = app.get_webview_window("main").unwrap();
    // Register global shortcut and define its behavior
    app.global_shortcut()
        .on_shortcut(shortcut, move |_app, scut, event| {
            if scut == &shortcut {
                if let ShortcutState::Pressed = event.state() {
                    // Toggle window visibility
                    if main_window.is_visible().unwrap() {
                        main_window.hide().unwrap(); // Hide window
                    } else {
                        main_window.show().unwrap(); // Show window
                        main_window.set_focus().unwrap(); // Focus window
                    }
                }
            }
        })
        .map_err(|err| format!("Failed to register new shortcut '{}'", err))
        .unwrap();
}

/// Helper function to register shortcuts during application startup
fn _register_shortcut_upon_start(app: &App, shortcut: Shortcut) {
    let window = app.get_webview_window("main").unwrap();
    // Initialize global shortcut and set its handler
    app.handle()
        .plugin(
            tauri_plugin_global_shortcut::Builder::new()
                .with_handler(move |_app, scut, event| {
                    if scut == &shortcut {
                        if let ShortcutState::Pressed = event.state() {
                            // Toggle window visibility
                            if window.is_visible().unwrap() {
                                window.hide().unwrap(); // Hide window
                            } else {
                                window.show().unwrap(); // Show window
                                window.set_focus().unwrap(); // Focus window
                            }
                        }
                    }
                })
                .build(),
        )
        .unwrap();
    app.global_shortcut().register(shortcut).unwrap(); // Register global shortcut
}

/// Retrieve the stored global shortcut as a string
pub fn _get_shortcut<R: Runtime>(app: &AppHandle<R>) -> String {
    let store = app
        .get_store(COCO_TAURI_STORE)
        .expect("Store should already be loaded or created");

    match store
        .get(COCO_GLOBAL_SHORTCUT)
        .expect("Shortcut should already be stored")
    {
        JsonValue::String(str) => str,
        unexpected_type => panic!(
            "COCO shortcuts should be stored as strings, found type: {} ",
            unexpected_type
        ),
    }
}

In the src-tauri/src/lib.rs file, import and register:

mod shortcut;

pub fn run() {
    let mut ctx = tauri::generate_context!();

    tauri::Builder::default()
        .plugin(tauri_plugin_store::Builder::default().build())
        .invoke_handler(tauri::generate_handler![
            shortcut::change_shortcut,
            shortcut::unregister_shortcut,
            shortcut::get_current_shortcut,
        ])
        .setup(|app| {
            init(app.app_handle());

            shortcut::enable_shortcut(app);
            enable_autostart(app);

            Ok(())
        })
        .run(ctx)
        .expect("error while running tauri application");
}

At this point, the app has implemented the functionality to toggle its visibility using a global shortcut.

The default shortcut for macOS is command+shift+space.
The default shortcut for Windows and Linux is ctrl+shift+space.

If the default shortcut conflicts with another application or the user has personal preferences, they can modify it.

Modify shortcut keys

Then you need to create a front-end interface to allow users to operate on the front-end interface.

import { useState, useEffect } from "react";
import { isTauri, invoke } from "@tauri-apps/api/core"; 

import { ShortcutItem } from "./ShortcutItem"; 
import { Shortcut } from "./shortcut"; 
import { useShortcutEditor } from "@/hooks/useShortcutEditor"; 
export default function GeneralSettings() {
  const [shortcut, setShortcut] = useState<Shortcut>([]);

  async function getCurrentShortcut() {
    try {
      const res: string = await invoke("get_current_shortcut"); 
      console.log("DBG: ", res); 
      setShortcut(res?.split("+")); 
    } catch (err) {
      console.error("Failed to fetch shortcut:", err); 
    }
  }


  useEffect(() => {
    getCurrentShortcut(); 
  }, []);


  const changeShortcut = (key: Shortcut) => {
    setShortcut(key); 
    if (key.length === 0) return; 
    invoke("change_shortcut", { key: key?.join("+") }).catch((err) => {
      console.error("Failed to save hotkey:", err); 
    });
  };

  const { isEditing, currentKeys, startEditing, saveShortcut, cancelEditing } =
    useShortcutEditor(shortcut, changeShortcut);


  const onEditShortcut = async () => {
    startEditing(); 
    invoke("unregister_shortcut").catch((err) => {
      console.error("Failed to save hotkey:", err); 
    });
  };

  const onCancelShortcut = async () => {
    cancelEditing(); 
    invoke("change_shortcut", { key: shortcut?.join("+") }).catch((err) => {
      console.error("Failed to save hotkey:", err); 
    });
  };


  const onSaveShortcut = async () => {
    saveShortcut(); 
  };


  return (
    <div className="space-y-8">
      <div>
        <h2 className="text-lg font-semibold text-gray-900 dark:text-white mb-4">
          General Settings
        </h2>
        <div className="space-y-6">
          <ShortcutItem
            shortcut={shortcut} 
            isEditing={isEditing} 
            currentKeys={currentKeys} 
            onEdit={onEditShortcut} 
            onSave={onSaveShortcut}
            onCancel={onCancelShortcut} 
          />
        </div>
      </div>
    </div>
  );
}

ShortcutItem.tsx file：

import { formatKey, sortKeys } from "@/utils/keyboardUtils";
import { X } from "lucide-react";
interface ShortcutItemProps {
  shortcut: string[];
  isEditing: boolean;
  currentKeys: string[];
  onEdit: () => void;
  onSave: () => void;
  onCancel: () => void;
}

export function ShortcutItem({
  shortcut,
  isEditing,
  currentKeys,
  onEdit,
  onSave,
  onCancel,
}: ShortcutItemProps) {
  const renderKeys = (keys: string[]) => {
    const sortedKeys = sortKeys(keys);
    return sortedKeys.map((key, index) => (
      <kbd
        key={index}
        className={`px-2 py-1 text-sm font-semibold rounded shadow-sm bg-gray-100 border-gray-300 text-gray-900 dark:bg-gray-700 dark:border-gray-600 dark:text-gray-200`}
      >
        {formatKey(key)}
      </kbd>
    ));
  };

  return (
    <div
      className={`flex items-center justify-between p-4 rounded-lg bg-gray-50 dark:bg-gray-700`}
    >
      <div className="flex items-center gap-4">
        {isEditing ? (
          <>
            <div className="flex gap-1 min-w-[120px] justify-end">
              {currentKeys.length > 0 ? (
                renderKeys(currentKeys)
              ) : (
                <span className={`italic text-gray-500 dark:text-gray-400`}>
                  Press keys...
                </span>
              )}
            </div>
            <div className="flex gap-2">
              <button
                onClick={onSave}
                disabled={currentKeys.length < 2}
                className={`px-3 py-1 text-sm rounded bg-blue-500 text-white hover:bg-blue-600 dark:bg-blue-600 dark:text-white dark:hover:bg-blue-700
                   disabled:opacity-50 disabled:cursor-not-allowed`}
              >
                Save
              </button>
              <button
                onClick={onCancel}
                className={`p-1 rounded text-gray-500 hover:text-gray-700 hover:bg-gray-200 dark:text-gray-400 dark:hover:text-gray-200 dark:hover:bg-gray-600`}
              >
                <X className="w-4 h-4" />
              </button>
            </div>
          </>
        ) : (
          <>
            <div className="flex gap-1">{renderKeys(shortcut)}</div>
            <button
              onClick={onEdit}
              className={`px-3 py-1 text-sm rounded bg-gray-200 text-gray-700 hover:bg-gray-300 dark:bg-gray-600 dark:text-gray-200 dark:hover:bg-gray-500`}
            >
              Edit
            </button>
          </>
        )}
      </div>
    </div>
  );
}

hooks/useShortcutEditor.ts file：

import { useState, useCallback, useEffect } from 'react';
import { useHotkeys } from 'react-hotkeys-hook';

import { Shortcut } from '@/components/Settings/shortcut';
import { normalizeKey, isModifierKey, sortKeys } from '@/utils/keyboardUtils';

const RESERVED_SHORTCUTS = [
  ["Command", "C"],
  ["Command", "V"],
  ["Command", "X"],
  ["Command", "A"],
  ["Command", "Z"],
  ["Command", "Q"],
  // Windows/Linux
  ["Control", "C"],
  ["Control", "V"],
  ["Control", "X"],
  ["Control", "A"],
  ["Control", "Z"],
  // Coco
  ["Command", "I"],
  ["Command", "T"],
  ["Command", "N"],
  ["Command", "G"],
  ["Command", "O"],
  ["Command", "U"],
  ["Command", "M"],
  ["Command", "Enter"],
  ["Command", "ArrowLeft"],
  ["Command", "ArrowRight"],
  ["Command", "ArrowUp"],
  ["Command", "ArrowDown"],
  ["Command", "0"],
  ["Command", "1"],
  ["Command", "2"],
  ["Command", "3"],
  ["Command", "4"],
  ["Command", "5"],
  ["Command", "6"],
  ["Command", "7"],
  ["Command", "8"],
  ["Command", "9"],
];

export function useShortcutEditor(shortcut: Shortcut, onChange: (shortcut: Shortcut) => void) {
  console.log("shortcut", shortcut)

  const [isEditing, setIsEditing] = useState(false);
  const [currentKeys, setCurrentKeys] = useState<string[]>([]);
  const [pressedKeys] = useState(new Set<string>());

  const startEditing = useCallback(() => {
    setIsEditing(true);
    setCurrentKeys([]);
  }, []);

  const saveShortcut = async () => {
    if (!isEditing || currentKeys.length < 2) return;

    const hasModifier = currentKeys.some(isModifierKey);
    const hasNonModifier = currentKeys.some(key => !isModifierKey(key));

    if (!hasModifier || !hasNonModifier) return;

    console.log(111111, currentKeys)

    const isReserved = RESERVED_SHORTCUTS.some(reserved =>
      reserved.length === currentKeys.length &&
      reserved.every((key, index) => key.toLowerCase() === currentKeys[index].toLowerCase())
    );

    console.log(22222, isReserved)


    if (isReserved) {
      console.error("This is a system reserved shortcut");
      return;
    }

    // Sort keys to ensure consistent order (modifiers first)
    const sortedKeys = sortKeys(currentKeys);


    onChange(sortedKeys);
    setIsEditing(false);
    setCurrentKeys([]);
  };

  const cancelEditing = useCallback(() => {
    setIsEditing(false);
    setCurrentKeys([]);
  }, []);

  // Register key capture for editing state
  useHotkeys(
    '*',
    (e) => {
      if (!isEditing) return;

      e.preventDefault();
      e.stopPropagation();

      const key = normalizeKey(e.code);

      // Update pressed keys
      pressedKeys.add(key);

      setCurrentKeys(() => {
        const keys = Array.from(pressedKeys);
        let modifiers = keys.filter(isModifierKey);
        let nonModifiers = keys.filter(k => !isModifierKey(k));

        if (modifiers.length > 2) {
          modifiers = modifiers.slice(0, 2)
        }

        if (nonModifiers.length > 2) {
          nonModifiers = nonModifiers.slice(0, 2)
        }

        // Combine modifiers and non-modifiers
        return [...modifiers, ...nonModifiers];
      });
    },
    {
      enabled: isEditing,
      keydown: true,
      enableOnContentEditable: true
    },
    [isEditing, pressedKeys]
  );

  // Handle key up events
  useHotkeys(
    '*',
    (e) => {
      if (!isEditing) return;
      const key = normalizeKey(e.code);
      pressedKeys.delete(key);
    },
    {
      enabled: isEditing,
      keyup: true,
      enableOnContentEditable: true
    },
    [isEditing, pressedKeys]
  );

  // Clean up editing state when component unmounts
  useEffect(() => {
    return () => {
      if (isEditing) {
        cancelEditing();
      }
    };
  }, [isEditing, cancelEditing]);

  return {
    isEditing,
    currentKeys,
    startEditing,
    saveShortcut,
    cancelEditing
  };
}

Summary

Through the introduction of this article, you can integrate global shortcuts into your Tauri application to provide users with a smoother operation experience. If you have not used Tauri yet, I hope you can have a deeper understanding of it through this article and start trying this feature in your own projects!

Open Source

Recently, I’ve been working on a project based on Tauri called Coco. It’s open source and under continuous improvement. I’d love your support—please give the project a free star 🌟!

This is my first Tauri project, and I’ve been learning while exploring. I look forward to connecting with like-minded individuals to share experiences and grow together!

Official website: coco.rs/
Frontend repo: github.com/infinilabs/coco-app
Backend repo: github.com/infinilabs/coco-server

Thank you for your support and attention!

Forem: Rain9

Are We Really Faster After AI Started Writing Our Code?

A Subtle Illusion of Efficiency

Why Does It Feel Slower?

1. You Save Implementation Time, But Increase Cognitive Load

2. Uncertainty Gets Amplified

3. We’re Using Old Processes with New Production Power

So, Are We Actually Faster?

Where AI Clearly Speeds Things Up

Where Things Get Slower (or Riskier)

The Real Problem Isn’t AI

How Do We Actually Get Faster?

1. Don’t Use AI Just to Write Code

2. Break Down Large Generations into Small Steps

3. Build a Trust Layer

4. Shift Testing Earlier

5. Accept the Trade-off: Less Execution, More Judgment

A Deeper Shift

Final Thoughts

I Got Tired of Boring Terminals — So I Built an AI That Walks on My Screen

🧠 It Started With a Simple Thought

👾 Meet CodeWalkers

🚶 Your AI... Now Has Legs

🖱️ The Magic Trick: Click-Through Transparency

💬 An AI Terminal That Feels… Alive

⏰ It Even Takes Care of You

⚡ Why Tauri + Rust?

🛠️ Tech Stack

🚀 Try It Yourself

🌱 Why I Open-Sourced It

💡 Final Thought

Tired of boring AI assistants? I built a "Desktop Pet" Copilot that wanders around your screen and writes code

🐶 What exactly is this?

🛠️ How does it work? (Let's talk tech)

1. Phantom Clicks: The Transparent Window Passthrough Problem

2. Stuffing a Real CLI into a Pet's Brain: PTY & Environment Variables

3. High FPS Animation Without Lag

🎨 Customization and Skins

🚀 Open Source & Contributing

react

AI

Building a Hugo + Tailwind technical blog from scratch: Taking INFINI Labs Blog as an example

Project Overview

1. Directory Structure: Where Do Content, Theme, Config, and Assets Live?

1) Content Layer: content/

2) Configuration Layer: hugo.toml + config/_default/*

3) Theme Layer: themes/hugoplate/

4) Asset Layer: assets/ vs static/

2. Build Pipeline: What Happens From Markdown to Final HTML/CSS/JS?

1) Build entry points: package.json scripts

2) Hugo Modules: Why does CI install Go?

3) How does Tailwind generate only the CSS you actually use?

4) How are CSS/JS bundled, minified, and fingerprinted?

3. Search: How Do index.json and /static/assets/* Work Together?

1) Where does the index come from?

2) Where does the search UI come from?

4. Building a Similar Project From Scratch (Minimum Viable Steps)

1) Prepare the toolchain

2) Install dependencies and start development

3) Add a new post

4) Build for production

5. Deployment & CI/CD: How Netlify / GitHub Pages / Vercel Build It

1) Netlify

2) GitHub Pages (GitHub Actions)

3) Vercel

Wrap-up: The Boundary Between Build-Time and Run-Time

next

useEffect

Tauri (9) - Implementing automatic startup of desktop applications

Introduction

Implementation Principle

Installing the Plugin

Rust Code Implementation

Frontend: Configuring Auto-Start

Conclusion

Open Source

tauri

Tauri (1) — A desktop application development solution more suitable for web developers ✅

Background

Introduction to Tauri

1) Content Layer: `content/`

2) Configuration Layer: `hugo.toml` + `config/_default/*`

3) Theme Layer: `themes/hugoplate/`

4) Asset Layer: `assets/` vs `static/`

1) Build entry points: `package.json` scripts

3. Search: How Do `index.json` and `/static/assets/*` Work Together?