Rebrand Wemod Launcher to Wand Launcher. - #235
Conversation
|
You think this i worth it. |
I do. We just want to keep this launcher going as long as possible, and Wand have advised me v11.x will stop working soon. |
shymega
changed the title
4bdd7cd to
ac12c4d
Compare
|
@marvin1099 See @pickworthi's analysis on Wand so far here: DeckCheatz/meta#1. |
Dam, i fear we may not ve able to do a lot here, may need to see if we can find some workaroud if any. |
|
Broadly speaking, we don't know if Wand have added DRM, or if its a security feature. At the moment, it looks like a issue with Wine itself, and we may need to open a upstream bug. |
Yea, not shure myself. |
ac12c4d to
f3bcd20
Compare
|
The download will always work when using a windows UA so that works, we can do that. |
3ca7d01 to
5ae82c6
Compare
|
Have you asked the wemod team about a nupg allways up to date link or soemthing like it. |
Yes, there's a CDN they have which shows a list of releases. I'm writing a parser for it, but the top line is always the latest. Currently I pulled it manually from the CDN. They still haven't responded to me via email though, and I've sent another email recently, with no reply. |
Is there a version string, then we could actually do auto updates of the exe, #248 would be a thing of the past. |
Yes, but the issue is that the new executables (i.e, Wand) do not work under Proton. So we can't do this yet. |
Yep i got that. |
b1b4520 to
0e6f38c
Compare
d528060 to
b4bffe4
Compare
Could you? |
|
Yes, sorry, missed this comment.
I'll discuss it with you in our group (private channel).
…On 30.04.2026 05:11, Marvin1099 wrote:
marvin1099 left a comment (DeckCheatz/wemod-launcher#235)
> Could you post the CDN, im curious what we are working with. Also as future reference.
Could you?
Or you can send it to me in private.
I'm still curious what we are working with.
--
Reply to this email directly or view it on GitHub:
#235 (comment)
You are receiving this because you were assigned.
Message ID: ***@***.***>
|
I did try some more request and did end up finding it, dont worry. |
2e8bb28 to
0de6fe6
Compare
0de6fe6 to
d7fd933
Compare
- Add format_size() helper to convert bytes to KB/MB/GB/TB - Display progress as "45% (12.5 MB / 27.8 MB)" instead of raw bytes - Increase text element width to accommodate formatted sizes - Reduce update interval from 1000ms to 100ms for smoother progress - Rename update_log to update_status for clarity Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Use thread-safe status list for progress updates instead of calling GUI methods directly from background threads - Move GUI updates to main event loop for reliable display - Fix swapped window titles in copy_folder_with_progress (was showing "Copying Prefix" for zip and vice versa) - Reduce update interval from 1000ms to 100ms for smoother progress - Add proper text element sizing for progress display Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add new copytree_with_progress() function in mainutils.py with thread-safe GUI progress updates - Replace shutil.copytree calls in syncwemod() with the new function - Shows "Copying WeMod Data" window with progress bar during sync - Handles destination directory creation automatically Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Adds get_mouse_location() function that uses tkinter to get the current mouse position, then passes this location to PySimpleGUI windows so they appear on the active screen in multi-monitor setups. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
To avoid ELF binary conflicts between Flatpak and host environments, virtual environments are now created in separate subdirectories: - wemod_venv/flatpak: For Flatpak sandbox environment - wemod_venv/host: For host system environment This ensures that binaries compiled for one environment don't get executed in the other, preventing "wrong ELF class" errors. Changes: - mk_venv(): Creates venv in appropriate subdirectory based on environment - venv_manager(): Checks for existing venv in correct subdirectory - check_flatpak(): Creates host venv in wemod_venv/host with dependencies - Adds venv detection to prevent infinite rerun loops
Adds support for running wemod-launcher on NixOS hosts, particularly when running from inside a Flatpak sandbox. NixOS requires special handling due to its non-standard filesystem layout and package management. Key features: - is_nixos(): Detects NixOS by checking /etc/NIXOS or /run/current-system/nixos-version - Works from inside Flatpak using flatpak-spawn to check host filesystem - get_python_command(): Wraps Python commands with nix-shell when needed - Provides access to python3, tkinter, and pip packages - Handles both Flatpak and host invocations NixOS venv creation: - Uses nix-shell ONLY during venv creation (not for subsequent invocations) - Creates venv with --copies flag to copy Python binary - Bootstraps pip using ensurepip module - Copies tkinter packages from nix-shell into venv's site-packages - Results in self-contained venv that works without nix-shell wrapper - Automatically installs dependencies from requirements.txt Changes: - mainutils.py: Add is_nixos() and get_python_command() functions - setup.py: Add NixOS-specific venv creation in mk_venv() and check_flatpak() - coreutils.py: Update pip() to use venv's bin/python directly, add NixOS comments 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
d7fd933 to
461fede
Compare
2 participants
WIP.