picacg-qt: a Qt PicACG client whose install path changes shape on every platform

The three platforms do not even unpack the same way

The install instructions are three separate procedures, not one procedure with different download links. On Windows, tested on Windows 10, you download the latest release, unzip the archive, and open `start.exe`. On macOS, tested on macOS 10.15.7, the archive is a 7z file that you extract and then drag the PicACG bundle into Applications from the Finder sidebar before launching it from Launchpad. On Linux, tested on deepin 20.2, the archive is `bika.tar.gz` and you expand it with tar. A reader who jumps between platforms has to relearn the launcher name and the packaging format each time, and a 7z extractor is a hard requirement on macOS since the archive is not a standard zip.

Windows updates mean downloading again and overwriting the folder

There is no auto-updater in the Windows flow. The stated update procedure is to download the newest version and overwrite the original directory, which means your installed copy lives wherever you unzipped it and there is no registry of installed versions. Nothing in the repository describes where settings or downloaded pages are stored, so a reader who overwrites the directory without backing it up has no documented way to recover local state. The one documented Windows failure is narrow and specific: if waifu2x cannot initialize and you get a DLL error, the fix is to install the Visual Studio runtime and the Vulkan runtime, both linked directly from the README.

waifu2x is the optional piece, and its dependencies are per platform

Upcaling is not bundled as a self-contained binary with no prerequisites, and the README treats it as a separate concern with a separate dependency chain. On Windows, a failed waifu2x initialization surfaces as a DLL error, and the answer is the Visual Studio redistributable plus the Vulkan runtime. On Linux, the requirement is stated differently: your device has to support Vulkan, and the driver package comes from the distribution, for example:

sudo apt install mesa-vulkan-drivers

The macOS section says nothing about waifu2x at all, which leaves a gap: there is no documented statement about what a Mac user needs for that feature, and the rest of the project credits the waifu2x work to nagadomi/waifu2x, waifu2x-ncnn-vulkan and tonquer/waifu2x-vulkan.

Linux starts with a .deb you install by hand

The Linux route is the only one that begins with a system package, and the dependency is pinned to a single old build from a Debian mirror. The documented steps download `libxcb-util1_0.4.0-1+b1_amd64.deb` from an ftp.br.debian.org pool path, install it with `sudo dpkg -i ./libxcb-util1_0.4.0-1+b1_amd64.deb`, then download the release and expand it:

tar -zxvf bika.tar.gz
cd bika && chmod +x start
./start

The archive extracts to a directory called `bika`, and the launcher is a script called `start` that has to be made executable first. Nothing explains why this specific version of the Qt xcb utility is required, and no alternative is offered for a distribution that does not use dpkg, so a reader on a non-Debian base has to find an equivalent package on their own.

Building runs on GitHub Actions, not on your machine

The compile section contains no local build command at all. It says to run `script/build_qrc.py` to generate the qrc file, then choose the matching system and architecture in the Actions workflow, and then look at the build result on the Actions page. That design has a clear cost: a fork that needs a change cannot simply build locally from the instructions,. The repository root does hold `build_mac.sh` and a `script/` directory, so the inputs for a build exist, but the wiring between them is not written down for a local run.

Proxy setup is one sentence and an issue number

Network access gets its own heading in the documentation and the content under it is a pointer, not an explanation: the proxy note tells the reader to look at issue tonquer#48. So the client that depends on a specific network path to reach its service does not state, anywhere in the repository, which environment variable to set, which host to point at, or what happens when the connection is simply unavailable. A reader who hits a blank list of comics has to leave the repository to find the answer, and whether issue 48 still matches the current release is not stated. Combined with an open issue count in the repository, that is a real support surface to plan for before relying on this client daily.

The feature set is two promises: read and download

The stated feature list is short. It claims that most of the PicACG comic service features are implemented, and it names two things directly: viewing images and downloading. The screenshots in `example/` match that scope, with files named for login, search, comic details, download, image viewing and waifu2x, which tells you the reading and search flow exists but says nothing about library management, offline caching, or update notifications. Because the project is a Qt interface over an online service, the interesting behaviour lives on the server side, and the repository does not describe any local format for the pages it caches. The maintainer's own framing is research oriented: the project states it is for technical study only.

LGPL-3.0 covers the shell, the credits carry their own terms

The repository is LGPL-3.0, which matters more for a Qt client with a Python primary language than the language label alone suggests: a desktop shell that links against a shared library has obligations a standalone script does not. Two sibling projects sit next to it, JMComic-qt and ehentai-qt, both under the same owner, and the README links them as related work rather than as forks or shared components, so nothing indicates that code moves between the three. The dependency credits are also specific: PyQt5 and PyQtClient for the Qt side, UN-GCPDS/qt-material and satchelwu/QSS-Skin-Builder for the theme, and zhiyiYo/Groove for smooth scrolling. Each is credited to a separate author with its own license, so a relicense of this client does not reach them.

Editorial conclusion

Pick picacg-qt if you want a desktop PicACG client on a machine you control and you are willing to sort out a runtime dependency yourself on Linux or a Visual Studio and Vulkan runtime on Windows. Pass if you need a signed installer, a working proxy story written down, or a build you can run locally. Before committing, check the release page for the archive format you need, read the proxy discussion in issue 48, and confirm that your device meets the Vulkan requirement the README gives for waifu2x.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. README
4. Releases
5. tonquer/picacg-qt on GitHub