A desktop pet has three separate delivery stages
An animated character, a controllable desktop application and a package that runs on somebody else's computer are separate outcomes. Build the core first, then customize appearance and interaction, then prepare distribution. This order keeps windowing, asset and packaging failures from becoming one indistinguishable problem. The example here is an original “cardboard fox”: offline by default, draggable, gently blinking when idle, and always offering pause and exit. It is a development plan and acceptance method, not a claim that an executable has been built or tested.
Before coding, specify the target operating system and architecture, Python and GUI versions, asset permissions, network behavior, configuration location and a complete exit path. Limit the first version to one character. Avoid adding startup registration or access to other applications as incidental features. Use fixed local dialogue before considering an optional language-model service. This leaves the core usable without an account or network connection and makes the first round of testing easier to interpret.
Stage one: choose a reference and establish the core
Search public implementations before creating another framework. The oyxdsg/Deepseek-pet repository is a relevant structural reference because its documentation identifies Python, PySide6, asset organization and a packaging route, and it declares an MIT license. That is enough to inspect it as a candidate, not to certify maintenance quality or platform compatibility. No code from it was executed for this article. Examine the actual source, dependency constraints, changes, issue history and license before reuse. Artwork and dependency terms need their own review; a project's MIT declaration does not replace the terms applicable to Qt/PySide6 or third-party images.
Create a project-specific virtual environment and record interpreter and package versions. Invoke package management through the intended interpreter so dependencies do not accidentally land in another Python installation. Begin with a normal window and one known-good PNG. Add the frameless setting, translucency and always-on-top behavior in separate steps. Qt documents specific translucent-window requirements on Windows, including the frameless flag. An image with an alpha channel alone does not make the surrounding top-level window transparent.
Keep the fox's first state machine small: idle, blink and dragged. Use timer-driven frame advancement instead of a blocking loop in the GUI thread. Define how each state begins and ends. During dragging, suspend autonomous movement; on release, return to a predictable resting state. Make pause, reset position and exit available from a menu so the user has a recovery route if the character is misplaced. Multiple monitors, display scaling and taskbar placement require their own checks rather than a calculation based only on the primary display's dimensions.
The first deliverables are a minimal source application, a version record and a state-transition sheet. Exercise repeated state changes, dragging toward every boundary, pausing, resuming and exiting. Record resource observations with their actual duration and environment; do not describe an unmeasured application as using no CPU. If the character interferes with work, provide hide or pause behavior. More random movement cannot compensate for missing user control.
Stage two: customize the character and its interactions
For replacement pixel artwork, agree on canvas dimensions, a foot baseline, transparent margins, naming and frame order. Keep the cardboard fox's idle frames on a consistent canvas so blinking does not unexpectedly resize its body. Store frame lists, timing and looping rules in an explicit asset manifest. Check missing files and duplicate frames before debugging the animation scheduler. Inspect the actual display scale, including the sampling method used when enlarging pixel art, rather than judging only the original image in an editor.
Distinguish a click from a drag. Record the press position, recognize dragging only after a chosen movement threshold, and avoid triggering a dialogue action on release after a drag. Keep visual animation state separate from persistent application state: closing a speech bubble should not reset the saved desktop position. Handle long text, line breaks and screen boundaries. Include Chinese and English example messages and a font fallback. Missing optional art should produce a clear fallback or diagnostic instead of an unexplained crash.
If chat is added, design offline behavior first. Perform requests without blocking the interface and define timeout, cancellation, repeat-click behavior and a usage budget. The pet should remain draggable while a reply is pending. Send only the dialogue the user intentionally submits; do not add clipboard, screen or file collection as an unstated convenience. Treat returned text as display content, not an executable instruction. Explain whether conversations are stored and how the user can remove them.
Do not embed a real API key in source or in a distributed executable. Let each user configure their own authorized service and continue with local features when no service is configured. Packaging is not a secret vault. Provider charges are separate from whether a skill or sample application is free. First test success, timeout and cancellation with a local simulated response; connect a real provider only with the relevant authorization and budget. Deliver an asset manifest, interaction rules and a network-extension note alongside the character customization.
Stage three: package a Windows application people can actually use
After source execution is stable, build a clean one-folder distribution first. Keep a console or useful logging during diagnosis, then prepare a user-facing GUI build. PyInstaller collects an interpreter and dependencies, so script size alone does not predict package size. Build for the intended operating system and architecture; do not assume an executable produced in another environment covers every Windows target. Preserve a spec file or build script that records resources, icons and required modules.
Resolve bundled resources relative to the appropriate application or module location and include them in matching paths. Do not rely on the directory from which a person happens to launch the program. Save mutable preferences and conversation data in an appropriate user-writable location, separate from application resources and temporary extraction areas. Reproduce the build in a clean environment to uncover accidental dependencies supplied by the development machine. Inspect dynamic imports and GUI plugins before removing libraries merely to reduce size.
One-file delivery is convenient but is not an antivirus-avoidance setting. PyInstaller documents temporary extraction of support files for that mode and recommends establishing a working one-folder build first. The source article's combination of “use onefile” and “avoid temporary extraction” should therefore not be copied as a general remedy. A digital signature can help identify a publisher without guaranteeing the absence of warnings. Retain detection reports, investigate the build and dependencies, and use a vendor's false-positive review process when appropriate. Do not ask recipients to disable security software to make an unknown build appear successful.
Distribute the full required folder or complete release package, with version, source, dependency notices, instructions and a checksum. Use a test environment without the development dependencies to inspect first launch, asset loading, paths containing spaces or non-Latin characters, settings persistence, offline operation, exit and relaunch. Keep personal configuration, real dialogue and credentials out of the release. State only the systems actually covered by testing. A successful double-click is the beginning of acceptance, not its entire definition.
Verified skills belong to specific supporting steps
The directory search for this article did not establish verifiable SkillPI entries corresponding to the source's desktop-pet and PyInstaller skill names. This guide therefore uses the reference project and official framework documentation for core implementation and packaging, rather than inventing six installation links. Future catalog additions can be assessed against the actual task, dependencies and expected artifacts. An installation count would not establish that a package fits this project.
Canvas Design can support an original static character concept board or instruction card in PDF or PNG. Supply dimensions, approved materials and an output location, then inspect the result. It does not establish frame-to-frame continuity, create a native window or package an executable. Animated sprites still need separate drawing and motion review; a static concept board is not a runnable character pack.
Writing Guidelines fits the technical handoff before sharing. Review requirements, launch instructions, pause and exit controls, configuration location, troubleshooting and concrete file references. It needs the documentation to review and access to its relevant writing rules. This is a clarity review, not a binary scan or a GUI test. Keep source evidence, static scanning and observed runtime behavior separate when describing either skill.
A practical first request and troubleshooting path
A bounded initial request is: “Plan an offline Windows cardboard-fox desktop pet. Return a state table, asset specification, project structure and dependency notes first. Limit the core to idle, blink, drag, pause and exit. Do not add an LLM or startup registration. After source execution has been verified, propose a PyInstaller one-folder build and list remaining unknowns.” This makes each stage inspectable and prevents an underspecified pet request from silently expanding into accounts, remote services and publication.
For an opaque window, start with one known alpha image, then inspect window attributes and painting behavior. For jitter, compare canvas sizes, baselines and scale. For frozen interaction, investigate sleeps or network work in the GUI thread. If the source works but a package loses pictures, inspect both resource collection and resource lookup. If double-clicking seems to do nothing, use a diagnostic console build to capture the error before changing multiple unrelated settings. A bubble outside the visible display suggests a problem with the selected monitor's available area or scaling coordinates.
FAQ and source record
Can a beginner start? A limited template and clear assets help, but interpreting startup errors and dependencies remains part of the work. Is Python mandatory? No; choose a maintainable stack for the target platform. Why is the package large? Inspect its interpreter, GUI libraries and assets in a clean build before assuming a defect. Can a build be guaranteed free of security alerts? No; provenance and testing are not a general safety certificate. Can chat be added? Yes, as an optional extension with explicit access, cost, key handling and offline fallback.
References include the Deepseek-pet repository, the Qt QWidget translucent-window documentation and PyInstaller's operating-mode and runtime-resource documentation. Both original-language article sources remain in the editorial record. The cardboard fox is an original teaching example rather than an already built product. Retain editable source, asset permissions, build settings, actual test environments and known limitations, and recheck the package when assets or dependencies change.