|
|
Hi William, This is very good news because I never find the courage to do it myself! I have a M4 Mac to test this change. I think the best is you fork on github, and send me the link for testing. Later after testing you can prepare for a pull request. But you have the all the time because I cannot do anything myself until the beginning of October. |
|
|
There is also a problem on Linux with the obsolete gtk2 interface, so I link the issue here so we not make incompatible change in each. |
|
|
Hey Patrick. I have tested this and evertthing looks good. You can build it with either the script supplied or manually, there are instructions in the fork. Please let me know if you have any questions or problems. I'd love to hear your or others feedback. https://github.com/thg4web/virtualmoon.git I can't wait to see how this works for you. |
|
|
Hello William, I try to compile the package but I get an FPC internal error. Can you tell me the FPC and Lazarus version you use. |
|
|
Patrick. my apologies, I did not include my scripts or compilation docs in the forked patches, I am working to get those in order as I was following them and found a couple of procedural issues, nothing to do with the code just the steps to install the dependencies and make a dmg file. It was a bit confusing and I am just sorting it out. I should have those by tomorrow my time EST -5. Thanks! |
|
|
Here is the hardware and software version I used to build this port: Hardware - Mac mini (Macmini9,1), Apple M1, 8 cores (4P+4E), 16 GB RAM OS - macOS 27.0.1 (Build 26A434), arm64 Dev tools - Xcode 26.6 (Build 17F113), CLT at /Applications/Xcode.app/Contents/Developer - Apple clang 21.0.0 (clang-2100.1.1.101) - git 2.50.1 (Apple Git-155) Pascal toolchain (via fpcupdeluxe, fresh default install, stable.gitlab target for both) - FPC 3.2.2 (release_3_2_2, git hash 0d122c49) "Stable" - Lazarus 4.8 (lazarus_4_8, git hash 62c14a4d) "Stable" - Installed at ~/fpcupdeluxe (fpcupdeluxe's own GUI-reported version metadata wasn't informative — use the symbolic names/git hashes above for exact reproduction instead) Bundled lib (for calclun/weblun TLS) - Homebrew 7.0.8, openssl@3 3.6.5, kegged at /opt/homebrew/Cellar/openssl@3/3.6.5/ Source - thg4web/virtualmoon, branch macos-cocoa-port, tip fd01412 |
|
|
Patrick, You should be good to go. I tracked down the procedural gap, tools/macos/README.md on the branch now walks through the whole thing start to finish (toolchain, base data, build, package), and I just re-verified it end to end on a second, completely clean Mac: fresh default install location fpcupdeluxe , nothing reused from my own machine. Built and ran without issue, using FPC 3.2.2 / Lazarus 4.8. Branch: macos-cocoa-port, now at tip 5caffac. Start here: tools/macos/README.md , it has both the manual steps and the two scripts (build-suite.sh, package-app.sh) that do it for you. Let me know what the internal error looked like if it happens again, so I can look into it. William |
|
|
Thank you! With your instruction I can build and run the program and it look very good. No more internal error. I have a question about the .app bundle and the location of the data (texture, database). When I do a Mac version in the past I have to put all this data in a directory outside of the .app. This is because there is additional packages to add more data, about 12 GB in total, and if I remember correctly installing one in the .app removed all the previous data. Do you have experience or AI advice about that? Patrick |
|
|
Good question, and I should have thought of that already, storing data inside the .app is exactly the kind of thing we do not want. I'll move it out to ~/Library/Application Support/Virtual Moon Atlas/, it's the same approach you used before, so the .app itself is just code and nothing about updating or reinstalling it touches the data. I'll let you know when I have that fix ready. One related question while I'm in there: I can have the build pre-populate basic/base data into that same folder on first launch, in a way that only fills in what's missing and never overwrites anything already there, so it wouldn't interfere with any add-on packages you or a user installed separately. Would you want that, or would you rather keep data provisioning entirely using separate downloads (like the Windows and Linux versions) and have the app just look for data in that location without ever writing to it itself? William |
|
|
For the next version 10 I plan to manage the data the same way as I already do for the last version of Skychart using an in-application downloader/installer. This is described here: https://groups.io/g/skychart/topic/new_catalog_for_beta_version/103738483 So maybe do not take too much time for this problem. I agree the .app ideally contain only the code. But it is good to have some basic data immediately available. Maybe a minimal data download can be done automatically the first time the program run, this way the .app can be clean. This is not only for the Mac version, but also for Linux and Windows, so it is best to do that out of this change. Now I will check your version work also on Windows and Linux with no regression. After that we can merge your changes. |
|
|
Saw your note on the data-location question, it makes sense, and good to know v10's heading toward a proper in-app downloader like you did for Skychart. Agreed that's the right long-term answer, and it's a cross-platform question anyway, so I won't spend any more time designing around it on the macOS side. For now, pushed a narrower fix to macos-cocoa-port (commit 7dc03a1) that just gets the .app itself clean — no data, no symlinks, matching what you said you want: 1. Contents/Resources now holds only atlun.icns and language — no Textures/Database/Encyclopedia bundled. Nothing data-related touches /Applications. 2. Added tools/macos/get-virtmoon-data.sh as a stopgap — fetches the SourceForge data packages into ~/Library/Application Support/Virtual Moon Atlas/ so the app has somewhere to find data until your v10 downloader exists. Not trying to be more than that. (If you already have the .deb files in the same directory directory as the script it'll use those instead of downloading them, a real time saver for repitive testing - do try the download to make sure it does work for you.) 3. Fixed a catlun bug the data split exposed: it hard-errored on texture levels L1/L2 without the separate high-res WAC pack installed. Now falls back to the base WAC_LOWSUN textures cleanly, same as L3–L6 already did. To test: pull macos-cocoa-port, build as usual (tools/macos/build-suite.sh then package-app.sh — no base-data step needed first anymore), install, then run get-virtmoon-data.sh once and pick at least the base package. Worth a quick check that catlun no longer errors with just the base package installed. I decided to use the .deb packages and just unpack them for our testing. But for a broader rollout we may need .zip files for macOS users as that will not need python or ar to unpack. Let me know if anything regresses for you, and good luck with the Windows/Linux pass. |
|
|
I test the new way to put the data in ~/Library/Application Support and this work fine. Also no problem with the Linux and Windows build. I think we are ready to merge you change. You can create the pull request now. |
|
|
William, To inform you I finish the change to install the Virtual Moon data from the program itself, see screenshot. This run automatically the first time atlun or cclun is launched. On Linux and Windows this also migrate the old data from the program directory. I not do it for the Mac because there is no previous version. This is in my master branch. The location of the data zip files is : https://vega.ap-i.net/pub/vmadata/ For people that install more than one computer or to install offline it is possible to download the files in advance. The button "Configure the data source" allow to select the local directory this files are. For me this work fine, but I am interested if you can test this new function. To test the new install you can delete or rename "~/Library/Application Support/Virtual Moon Atlas" Screenshot 2026-10-24 at 14.30.03.png (272,419 bytes) |
|
|
Hello Patrick, Thank you for the installer work. I tested the new first-run data install today and it worked great. Test setup: - Built from your master at 42bb0931 ("Sync indi client with skychart") on an Apple Silicon Mac (macOS 27.0.1, Xcode 26.6), using tools/macos/build-suite.sh and package-app.sh. - No ~/Library/Application Support/Virtual Moon Atlas existed beforehand, so this was a clean first run. - The installer started automatically at first launch and the data installed correctly. I did not test the "Configure the data source" local-directory option. But I did look at the "~/Library/Application Support/Virtual Moon Atlas/" data location and got this $ ls ~/Library/Application\ Support/Virtual\ Moon\ Atlas/ Base_Data_dir.txt Base_Data_version.txt data_list.txt doc Personnages Textures Base_Data_files.txt data Database Encyclopedia Pictures Looks like you are good to go and it works great! P.S. I sent you an email to your published email address from my email address "hikerdad" about a project I have been working on. Sincerely, William |
- Anonymous
