QKiSS

• KISS/GS (General Specification), with its extended comments.
• FKiSS (the script language): versions 1 and 2.

That is quite enough to load nearly all the Japanese KiSS sets I could find on the Internet.

But I deliberately decided not to implement the shell() command, to avoid unnecessary security holes. (I don't think I've ever seen a KiSS set that uses it, either.)

I have no Mac. So, no idea.

A KiSS viewer implemented in Qt 6. Having “KiSS” in the name is a convention of KiSS viewers, like fkiss, GnomeKiSS, KISSLD, and Direct KiSS.

I also considered a few other names:

• QtKISS: pronounced the same as “Cute Kiss”, and named with the same logic as GnomeKiSS: “platform name + KiSS”. Well, actually, QKiSS had this name in the early days of development. But according to the fair use rules of the Qt trademark, the Qt name may only be used “where the Qt name is not being used in a way which suggests sponsorship or endorsement of the product”. To avoid someone giving me crap about it someday, I had to rename it.
• Qute KISS: also pronounced “Cute Kiss”, but argh… Qute is a trademark of a Japanese computer game company. Too risky.

The biggest archive right now is probably Otaku World, though you have to dig through it patiently. It has sets by both Japanese and Western artists.

Some people have also written their own implementations, such as one in JavaScript or one in Haskell, with online demos you can open right in your browser. But most of the sample sets they provide were dug up from Otaku World, too.

Note that these KiSS sets may contain NSFW content, and I can't make any guarantees.

LZH / LHA is a free compression format and tool, developed in 1988 by Haruyasu Yoshizaki, a Japanese physician. It was very popular in the Japanese personal computer scene of the time (by comparison, PKZIP, the ZIP tool that later became the mainstream, did not appear until 1989, and was shareware), so the KiSS developer community, which originated in Japan, naturally adopted LZH to compress KiSS sets.

But today, both the format and its implementations are old, and lha and unar extract LZH files of unknown origin, which makes them the easiest target for a malicious file. So on Linux, QKiSS locks them up:

• Landlock: they can read only the system files and the archive being opened, nothing else in your home folder, and they can write nowhere except unar's temporary folder.
• seccomp: high-risk system calls such as io_uring, sockets and namespaces are turned off.
• AppArmor (the optional qkiss-apparmor package, Debian / Ubuntu / openSUSE only): lha and unar are restricted once more, and QKiSS itself cannot read secrets such as ~/.ssh, nor write files used for persistent attacks, such as ~/.bashrc.

Landlock and seccomp are built into QKiSS, with nothing to install, but they cover only these two external programs, not QKiSS itself.

As for Windows: as Eisen once said, anyone who uses Windows is a brave warrior, and needs none of these little tricks.

It doesn't fit the use case. SELinux's security model is inherently bad at “deny access to a few folders such as ~/.config/autostart, and allow access to everything else”, and I can't force users to put their KiSS LZH files only into some hardcoded ~/qkiss folder.

Besides, on the Linux desktop, people who deliberately run GUI apps outside unconfined_t must be rare. Such people either work at the Pentagon^*1, or moved to Qubes OS long ago.

But even if you use SELinux, you still have the protection of Landlock and seccomp, which covers only the extraction by the two external programs, lha and unar.

Although I already mentioned that this project was meant to be a “native desktop application”^*1 from the start, this is a question people really do ask sometimes, so let me answer it here anyway.

I know there are some KiSS implementations which can run in a Web browser by using Web technologies directly, but they are (technically and architecturally) awkward when you want to turn them into a desktop application integrated with your OS and file system; and such a thing which actually can be done in a lightweight way should not need a browser at all.

On top of that, I would have to keep chasing Electron's breaking API changes, there's npm, a super uncontrollable thing that makes packaging a hassle and can even get poisoned, and the compatibility between Node versions and Electron versions to deal with (not to mention the versions of each distro)...., and so on and so forth. Taking all of this into account, for a small project like QKiSS, I don't believe at all that developing and maintaining it with Electron or Web technologies would cost less, and I can guarantee that I would have a miserable time developing and maintaining it.

• I'm a KDE user, and Qt feels the most seamless to use.
• Qt Widgets is mature and stable: its major versions last for years, with few API breaks. I don't have to build any widgets myself, and I can get 80% of the features done with hardly any third-party libraries.
• Rust would need a binding, and then I'd have to worry about its API breaks, its quality and its extra pitfalls, plus the Qt C++ patterns that don't translate directly into Rust. I'd have two things to keep up with, Qt and the binding, and I'd lose all the help from Qt Creator.
• I want to practice C++.

• This project does use help from LLMs, but keeps it under control as much as possible, with various engineering methods (e.g. isolating LLM agents in KVM virtual machines, the principle of least privilege, and reviewing commits by hand).
• No damn vibe coding, ever, in the main program (Qt / C++) or in the Python code. Even with help from LLMs, the code was reviewed and modified by hand, line by line: I can understand and explain every line of it. I also proofread the translations by hand, as much as my broken foreign languages allow.

How much LLMs directly generated in each area

• Qt / C++ 5%
  • Microsoft Copilot
  • ChatGPT
  • Claude

  Discussing design patterns, finding suitable Qt APIs, and writing some examples for difficult Qt APIs (e.g. the delegates of MVC).

• Python 40%
  • Microsoft Copilot
  • ChatGPT

  Rough scaffolds (e.g. argparse) and some snippets. Learning the latest “Pythonic” ways, and the best practices of type annotations in Python 3.

• Translations 80%
  • Microsoft Copilot
  • Codex
  • Claude Code

  Translating the strings in *.ts from English or Japanese into the other languages, then fixing them by hand, line by line.

• FKiSS specification Docstrings only
  • Claude

  Collecting all the FKiSS commands from the FKiSS references in HTML, and organizing them into a formal list and docstrings in fkiss.cpp.

• CMake 60%
  • ChatGPT
  • Gemini

  Surveying and discussing the best practices of CPack and CMakePresets.json for a cross-platform Qt app. Learning Windows packaging, NSIS and the deployment of DLLs.

• GitHub Actions 60–70%
  • Gemini
  • ChatGPT
  • Claude Code

  For the Windows packages (I have no Windows development environment). Before the public release, I realized that fighting this was a waste of time, so I let an LLM agent debug it and write the rest of the code.

• osc / RPM / DEB 40–70%
  • Gemini
  • ChatGPT
  • Claude Code

  Learning the many detailed rules of DEB and RPM packaging, troubleshooting, and how to build locally with osc. Discussing how to connect the CI/CD of GitHub Actions to the _service of OBS. Before the public release, I let an LLM agent debug it and write the rest of the code.

• Security measures 90%
  • Claude
  • Claude Code
  • ChatGPT

  Claude Code is in charge of directly writing the code that uses Linux APIs like Landlock and seccomp. It is also in charge of extracting the parts suitable for QKiSS from the AppArmor profiles that the author of QKiSS uses privately, and organizing them into compatible packages for each distro. ChatGPT also took part in the security review of the C++ code.

• This website 80%
  • Claude Code

  All the translations, and all the HTML / CSS / JS… I can't be bothered anymore to spend my free time writing web pages.

• Icons 0%

  Tango / Nome / Humanity are all forked from versions of the era before LLMs appeared. All the icons forked afterwards, and QKiSS's own icons, are hand-drawn by the author of QKiSS with Inkscape.

• Writing 0%
  • Claude Code

  All the text of this website and the README is hand-written by a human. LLMs are only in charge of translation or grammar correction, and of talking the author out of writing anything even more aggressive.

…Argh, I guess this might be my last project whose code is mainly written by hand… Not only KiSS itself: another era is over.