[Windows] Transparent Desktop Mode

[honza0777]

✅ What this Pull Request adds

This PR introduces an optional transparent desktop mode for Windows, making PyDeskMates behave much closer to original DeskMate-style companions:

✔ Borderless & transparent window (no grey background)
✔ Character appears directly on the desktop instead of an opaque window
✔ Window can optionally attach to WorkerW (behind desktop icons)
✔ Still interactive – sprite can be clicked or dragged
✔ No effect on Linux/macOS (code runs only if sys.platform == "win32")

---

💡 Why this is useful

• Characters look like they are “walking freely on the desktop”
• Much closer to the original Japanese DeskMate behaviour
• Keeps full interactivity (drag & drop character, mouse interactions)
• Does not break existing code or platforms

---

⚙ Technical Summary

• Uses Win32 layered window + color key (SetLayeredWindowAttributes)
• Default background color (64,64,64) is made fully transparent
• Pygame window is created with pg.NOFRAME | pg.SRCALPHA on Windows
• Window can be attached to desktop surface (WorkerW)

To disable desktop embedding, just comment this line:

put_window_on_desktop(hwnd)

**Modified file (example implementation):**  
➡️ View: https://gist.github.com/honza0777/5228c1af4ff9d16457e8a084d0667f9c  
➡️ Raw (download): https://gist.githubusercontent.com/honza0777/5228c1af4ff9d16457e8a084d0667f9c/raw/main.py

Tested on: Windows 11 (Python 3.10 + pygame 2.6.1)
Likely compatible with: Windows 10, but not explicitly tested

This feature is optional and can be easily disabled by commenting out one line.

Let me know if you'd prefer this behind a config option (e.g. in config.ini), or if I should convert it into a toggle instead of default behavior.

[DimaLeon2000]

Why is this added as an issue instead of as a pull request?

[honza0777]

I understand your point.
The reason I submitted this as an issue first is because:

• I wanted to ask for your approval before creating a pull request,
• I wasn’t sure if you would like this feature to be merged by default or behind a config option,
• and I thought it might be better to discuss it with you first before making a formal PR.

If you are OK with it, I can create a proper pull request with the modified main.py (or another structure you prefer).

Let me know what works best for you.

[DimaLeon2000]

There's one problem: The sprite is completely invisible on my desktop with put_window_on_desktop(hwnd) and explorer.exe on.

[honza0777]

I found the cause and fixed it locally.

The problem was this line:

self.data_directory = working_directory + '\characters\' + character + '\Data\'

In my setup character already points directly to the character folder
(e.g. kahli3D, TestChar), so this path was incorrect and frames were not loaded.

Reverting it back to:

self.data_directory = working_directory + '\' + character + '\Data\'

fixed the issue and the app works correctly again.

This seems to be independent of the transparent / WorkerW changes.

[DimaLeon2000]

I found the cause and fixed it locally.

The problem was this line:

self.data_directory = working_directory + '\characters' + character + '\Data'

In my setup character already points directly to the character folder (e.g. kahli3D, TestChar), so this path was incorrect and frames were not loaded.

Reverting it back to:

self.data_directory = working_directory + '' + character + '\Data'

fixed the issue and the app works correctly again.

This seems to be independent of the transparent / WorkerW changes.

That's not the cause. Also, the entire character folder (not the contents of it) should be in the "characters" folder, not in the root directory, like so: \characters\Kahli\.

[honza0777]

Got it, thanks for the clarification.

You're right – the project expects the character folders to be located under
the characters/<name>/Data structure.

My local setup didn’t follow that layout, which explains why reverting the path
worked for me, but I understand this is outside the intended project structure
and not the root cause of the WorkerW issue.