GoldenCheetah v3.7 on macOS status

[Ale Martinez]

The purpose of this thread is to discuss about macOS specific issues and build alternatives, full disclosure I am not a macOS developer or even a regular user, so help and ideas are welcome.

Current official macOS build is feature complete for Intel Macs (X86-64 arch): 

GoldenCheetah V3.7 (5005)

Build date: Mar 29 2025 01:51:11
Build id: 5005
Version: V3.7
DB Schema: 160
Metrics: 382
OS: macOS 12.6
UI: dpi scale (0) font size (-1)

QT: 5.15.7
QWT: 6.8.0
GCC: 4.2.1
SRMIO: yes
D2XX: yes
ICAL: 3.0
USBXPRESS: none
LIBUSB: yes (1.0)
VLC: 3.0.8 Vetinari
VIDEO: vlc
SAMPLERATE: 0.1.9
SSL: yes
R: none [4.1.1]
Python: none [3.7.9]
LMFIT: 7.0
GSL: 2.7.1

Like other builds based on Qt5.15 the internal web browser is rather old, so you may experience problem when accessing external web sites s.t. Garmin Connect or Strava.

Unlike Windows and Linux, we currently don't have a prebuilt binary for macOS using Qt6.

On Apple Silicon Macs you need Rosetta to run it so performance is not as good as it could be if it were a native ARM64 build and, if you want R integration you need to install an X86-64 version of R since macOS doesn't support mixed architecture libraries.

Currently the solution for these limitations is to build from source, the process described in INSTALL-MAC document is relatively straight forward provided you have some knowledge of the tools or are willing to learn, but if your idea to install a Mac App is limited to download it from App Store, it is not likely for you.

I did this myself on macOS 15 Sequoia on an ARM64 Mac using Qt 6.8.3 (HomeBrew already switched to 6.9.0 and I prefer not to use .0 versions) and it works as expected.

My original intention was to create a dmg bundle but regrettably the bundle doesn't run standalone, as explained here code signing seems to be mandatory, and the process seems to be somewhat involved (Signing your apps for Gatekeeper). I am not sure how it applies to FOSS projects.

If you have related questions, please use this thread, ideas and collaboration are welcome.

Cheers, Ale.

[Joachim Kohlhammer]

Ale Martinez schrieb am Freitag, 11. April 2025 um 01:23:49 UTC+2:

Like other builds based on Qt5.15 the internal web browser is rather old, so you may experience problem when accessing external web sites s.t. Garmin Connect or Strava.

Unlike Windows and Linux, we currently don't have a prebuilt binary for macOS using Qt6.

On Apple Silicon Macs you need Rosetta to run it so performance is not as good as it could be if it were a native ARM64 build and, if you want R integration you need to install an X86-64 version of R since macOS doesn't support mixed architecture libraries.

Currently the solution for these limitations is to build from source, the process described in INSTALL-MAC document is relatively straight forward provided you have some knowledge of the tools or are willing to learn, but if your idea to install a Mac App is limited to download it from App Store, it is not likely for you.

I did this myself on macOS 15 Sequoia on an ARM64 Mac using Qt 6.8.3 (HomeBrew already switched to 6.9.0 and I prefer not to use .0 versions) and it works as expected.

My original intention was to create a dmg bundle but regrettably the bundle doesn't run standalone, as explained here code signing seems to be mandatory, and the process seems to be somewhat involved (Signing your apps for Gatekeeper). I am not sure how it applies to FOSS projects.

If you have related questions, please use this thread, ideas and collaboration are welcome.

Let me chime in as I am currently (not full power but with some first results) looking into GIthub Actions:

• Compiled successfully for both Intel and ARM64 (no secrets, no additional features like Python)
• Brew on the GitHub provided runner for intel (macos13, Standard GitHub-hosted runners for public repositories) does not include the required modules  webenginecore webenginewidgets webenginequick for Qt6. Therefore falling back to Qt5 for this architecture
• The brew provided Qt installations have rpath issues, therefore dmg-bundling using macdeployqt does not work yet (many more of these messages):
  • ERROR: Cannot resolve rpath "@rpath/QtPositioning.framework/Versions/A/QtPositioning"
    886ERROR: using QList("/Users/runner/work/GoldenCheetah/GoldenCheetah/src/lib")

About my ties to Apple and Mac: Despite having a solid Unix / Linux background, my knowledge about MacOS specifics from a developers standpoint is absolutely zero. I do have a MacBook on my desk, but this is a fully managed company device I am not able to use for anything besides work. So help on the aforementioned - and upcoming - topics is very welcome and necessary.

Cheers

Joachim

[Chris Cleeland]

I am in a similar situation to Joachim: deep linux/unix development experience as both day job and small hobby, but very little modern MacOS development, and almost nothing on Qt other than what I've done on GC in the past.

I have a personal intel MBP suitable for development, and a fully managed corporate ARM mac also suitable for development.  Since I use the corp mac for development at work, I have enough control that I can do builds on it. We do have a corp policy on open source contributions, but it's old and a bit murky, so I'd need to check.  For the most part, I try to keep work and hobby separated.

We have a small team in corp that does development on macs just enough to support the corp mac infra.  If there's a short list of the deployment issues, I can try to reach out to somebody to see if they know the answers, or can at least point me at a person who can help find the answers.

--
_______________________________________________
Golden-Cheetah-Users mailing list
golden-che...@googlegroups.com
http://groups.google.com/group/golden-cheetah-users?hl=en
---
You received this message because you are subscribed to the Google Groups "golden-cheetah-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golden-cheetah-u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golden-cheetah-users/7e83092e-7403-4795-b5a2-d190166b95ebn%40googlegroups.com.

--

Chris Cleeland

[Ale Martinez]

El viernes, 11 de abril de 2025 a la(s) 3:13:19 a.m. UTC-3, Joachim Kohlhammer escribió:

Ale Martinez schrieb am Freitag, 11. April 2025 um 01:23:49 UTC+2:

Like other builds based on Qt5.15 the internal web browser is rather old, so you may experience problem when accessing external web sites s.t. Garmin Connect or Strava.

Unlike Windows and Linux, we currently don't have a prebuilt binary for macOS using Qt6.

On Apple Silicon Macs you need Rosetta to run it so performance is not as good as it could be if it were a native ARM64 build and, if you want R integration you need to install an X86-64 version of R since macOS doesn't support mixed architecture libraries.

Currently the solution for these limitations is to build from source, the process described in INSTALL-MAC document is relatively straight forward provided you have some knowledge of the tools or are willing to learn, but if your idea to install a Mac App is limited to download it from App Store, it is not likely for you.

I did this myself on macOS 15 Sequoia on an ARM64 Mac using Qt 6.8.3 (HomeBrew already switched to 6.9.0 and I prefer not to use .0 versions) and it works as expected.

My original intention was to create a dmg bundle but regrettably the bundle doesn't run standalone, as explained here code signing seems to be mandatory, and the process seems to be somewhat involved (Signing your apps for Gatekeeper). I am not sure how it applies to FOSS projects.

If you have related questions, please use this thread, ideas and collaboration are welcome.

Let me chime in as I am currently (not full power but with some first results) looking into GIthub Actions:

• Compiled successfully for both Intel and ARM64 (no secrets, no additional features like Python)
• Brew on the GitHub provided runner for intel (macos13, Standard GitHub-hosted runners for public repositories) does not include the required modules  webenginecore webenginewidgets webenginequick for Qt6. Therefore falling back to Qt5 for this architecture
• The brew provided Qt installations have rpath issues, therefore dmg-bundling using macdeployqt does not work yet (many more of these messages):
  • ERROR: Cannot resolve rpath "@rpath/QtPositioning.framework/Versions/A/QtPositioning"
    886ERROR: using QList("/Users/runner/work/GoldenCheetah/GoldenCheetah/src/lib")

Hi Joachim, official distributions don't have these issues, there is a Python helper you can try to install them in CI environments: https://pypi.org/project/aqtinstall/

[Ale Martinez]

El viernes, 11 de abril de 2025 a la(s) 11:23:36 a.m. UTC-3, Chris Cleeland escribió:

I am in a similar situation to Joachim: deep linux/unix development experience as both day job and small hobby, but very little modern MacOS development, and almost nothing on Qt other than what I've done on GC in the past.

I have a personal intel MBP suitable for development, and a fully managed corporate ARM mac also suitable for development.  Since I use the corp mac for development at work, I have enough control that I can do builds on it. We do have a corp policy on open source contributions, but it's old and a bit murky, so I'd need to check.  For the most part, I try to keep work and hobby separated.

We have a small team in corp that does development on macs just enough to support the corp mac infra.  If there's a short list of the deployment issues, I can try to reach out to somebody to see if they know the answers, or can at least point me at a person who can help find the answers.

Hi Chris, I have 2 questions:

1) Is there any way to avoid code signing to distribute modern macOS Apps? Otherwise which would be the way to approach code signing for a FOSS project?

2) How to cross-compile using qmake on ARM64 Mac to have an X64 binary?

Thank you! 

[Chris Cleeland]

On Fri, Apr 11, 2025 at 5:27 PM Ale Martinez <amtri...@gmail.com> wrote:

Hi Chris, I have 2 questions:

1) Is there any way to avoid code signing to distribute modern macOS Apps? Otherwise which would be the way to approach code signing for a FOSS project?

I sent this question on.

 

2) How to cross-compile using qmake on ARM64 Mac to have an X64 binary?

I'm not sure what the significance of using qmake vs. anything else is, but I know that when you use apple's toolchain, you can build universal binaries (they include object code for both architectures) by specifying multiple `-arch` parameters to the compiler and linker, e.g.,

cc -arch x86_64 -arch arm64 hello.c

will generate an executable that can run natively on either platform.  The host platform can be intel or apple silicon.  It looks like you can tell qmake to add those by tweaking QMAKE_CFLAGS/CXXFLAGS/LDFLAGS in the .pro file.  ChatGPT also seems to think that QMAKE_APPLE_DEVICE_ARCHS is a valid variable to set in the .pro file to generate universal binaries/libraries, e.g.,

QMAKE_APPLE_DEVICE_ARCHS = x86_64 arm64

The problem is that I'm not sure that all the libraries brought in via homebrew will be universal, and IIRC there are a LOT of libraries that GC gets from homebrew.  If they're not available universal, then you'd need to compiler them universal on installation, and that might require customizing the brew recipe.  Yuck.  Dependencies are a pain.

--

Chris Cleeland

[Joachim Kohlhammer]

Ale Martinez schrieb am Samstag, 12. April 2025 um 00:23:32 UTC+2:

Hi Joachim, official distributions don't have these issues, there is a Python helper you can try to install them in CI environments: https://pypi.org/project/aqtinstall/

 

Great hint Ale, using aqt I was able to successfully create (simple again, no Python, no R, no Video, ...) builds for both x86 and arm64 using GitHub Actions based on Qt6:

• https://github.com/thejockl/GoldenCheetah/actions/runs/14423422771
• https://github.com/thejockl/GoldenCheetah/actions/runs/14423422771/attempts/1

The additional run was required as creating the dmg-file failed for the x64 build in first attempt but succeeded on a second without change.

Can someone with a Mac please test if the images are installable - and contain a runnable GoldenCheetah?

[Ale Martinez]

El domingo, 13 de abril de 2025 a la(s) 3:51:26 a.m. UTC-3, Joachim Kohlhammer escribió:

Ale Martinez schrieb am Samstag, 12. April 2025 um 00:23:32 UTC+2:

Hi Joachim, official distributions don't have these issues, there is a Python helper you can try to install them in CI environments: https://pypi.org/project/aqtinstall/

 

Great hint Ale, using aqt I was able to successfully create (simple again, no Python, no R, no Video, ...) builds for both x86 and arm64 using GitHub Actions based on Qt6:

• https://github.com/thejockl/GoldenCheetah/actions/runs/14423422771
• https://github.com/thejockl/GoldenCheetah/actions/runs/14423422771/attempts/1

The additional run was required as creating the dmg-file failed for the x64 build in first attempt but c on a second without change.

Can someone with a Mac please test if the images are installable - and contain a runnable GoldenCheetah?

Great, good progress!

I tried both dmg on an ARM64 MacBook running latest Sequoia (15.4) and after mount neither allowed to copy the package or run from there, but results were different:

• For the x64 version I could cp -r /Volumes/GoldenCheetah to the local file system and run from there successfully.
  
• For the ARM64 version nothing worked, macOS message is the package is damaged but the kill 9 is similar to what I got with my local build running stand alone, so it seems code signing failure is the problem here too.

 I think we need to figure out how to sign the code since newer macOS seems to be increasingly restrictive otherwise.

[Ale Martinez]

PS: our official x64 builds were generated using Xcode 14.2, if that were an option on GitHub runners using it likely would avoid the signing issue, at least for x64 versions.

[Ale Martinez]

PPS: on Travis-ci I had added a standalone test for the generated dmg, which later I removed due to running time constraints, but it could be useful for your tests:

echo "Mounting dmg file and testing it can execute"
hdiutil mount $FINAL_NAME
cd /Volumes/GoldenCheetah
GoldenCheetah.app/Contents/MacOS/GoldenCheetah --version

[Joachim Kohlhammer]

Ale Martinez schrieb am Sonntag, 13. April 2025 um 20:50:40 UTC+2:

I tried both dmg on an ARM64 MacBook running latest Sequoia (15.4) and after mount neither allowed to copy the package or run from there, but results were different:

• For the x64 version I could cp -r /Volumes/GoldenCheetah to the local file system and run from there successfully.
  
• For the ARM64 version nothing worked, macOS message is the package is damaged but the kill 9 is similar to what I got with my local build running stand alone, so it seems code signing failure is the problem here too.

 I think we need to figure out how to sign the code since newer macOS seems to be increasingly restrictive otherwise.

Thanks for trying out! I  agree that finding a solution for signing and even more importantly notarizing the code is the most important topic for now.

My priorities are as follows:

1. Rudimentary Build (x86 + arm64) - done
2. Signing + Notarizing (or how to bypass)
3. Secrets management + injection
4. Adding all required dependencies
5. Preparation for various situations (PR, master, releases)
6. Finetuning

I will try finding out how strict the signing / notarizing rules are and what this means for us. Maybe your proposal with an older xcode-version could be a first step.

 

[Ale Martinez]

It looks like a good plan going forward!

For now I rescued an old Intel MacBook with macOS 12.7 (Monterrey), installed Xcode 14.2, Qt 6.8.3 and the rest of dependencies and generated a dmg which is available from https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/v3.7, it is only minimally tested to the point it can be installed and run on the same MacBook and on a newer one with Apple Silicon running macOS 15.4 (Sequoia):

[Ale Martinez]

El miércoles, 16 de abril de 2025 a la(s) 7:36:39 p.m. UTC-3, Ale Martinez escribió:

El lunes, 14 de abril de 2025 a la(s) 4:58:09 a.m. UTC-3, Joachim Kohlhammer escribió:

Ale Martinez schrieb am Sonntag, 13. April 2025 um 20:50:40 UTC+2:

I tried both dmg on an ARM64 MacBook running latest Sequoia (15.4) and after mount neither allowed to copy the package or run from there, but results were different:

• For the x64 version I could cp -r /Volumes/GoldenCheetah to the local file system and run from there successfully.
  
• For the ARM64 version nothing worked, macOS message is the package is damaged but the kill 9 is similar to what I got with my local build running stand alone, so it seems code signing failure is the problem here too.

 I think we need to figure out how to sign the code since newer macOS seems to be increasingly restrictive otherwise.

Thanks for trying out! I  agree that finding a solution for signing and even more importantly notarizing the code is the most important topic for now.

My priorities are as follows:

1. Rudimentary Build (x86 + arm64) - done
2. Signing + Notarizing (or how to bypass)
3. Secrets management + injection
4. Adding all required dependencies
5. Preparation for various situations (PR, master, releases)
6. Finetuning

I will try finding out how strict the signing / notarizing rules are and what this means for us. Maybe your proposal with an older xcode-version could be a first step.

It looks like a good plan going forward!

For now I rescued an old Intel MacBook with macOS 12.7 (Monterrey), installed Xcode 14.2, Qt 6.8.3 and the rest of dependencies and generated a dmg which is available from https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/v3.7

It's been a week without feedback about this build, history says when there are problems they are immediately reported, so the options are:

1) It works as expected

2) There is no interest

The difference is relevant since we could make Qt6 builds default for v3.7, but without feedback perhaps it is better to keep them unchanged.

[TJDunnigan]

Hi Ale,

Sorry for the delay, I've been under the weather. I installed this new release and it seems to be functioning well. No faults upon starting or closing. It seems to me that it is far quicker to load and switch views than previous Mac versions. I will try to run a train session tomorrow.

[mondoshiwan]

Hi,

same here QT6 Version is running without issues so far on Ventura 13.7.5 | M2 Mac Mini.

R- and Python-Charts are working with the external frameworks.

and yes it's a little bit faster than the QT5 Version from March.

[TJDunnigan]

For me, it's remarkably faster when switching from Activities view to Train view. That used to take up to 30 seconds to load and now is immediate. My erg session also ran fine.

A complex Python chart, that formerly crashed the program (about 30% of the time) when switching to it, has not caused a crash since upgrading.

Thanks all

[mondoshiwan]

just checked switching from Activities to Train View and Yes it will switch instantly instead of waiting 30 sec looking at the spinning beachball.

But… if a ANT+ Stick is plugged in, the QT 5 Version will also switch immediate.

So this will be relevant for all people only using a Bluetoth connection without using an ANT+ Stick.

[Steve Edmonds]

I use an ANT+ stick on my Mac, I got the 30 second delay with Qt5, Qt6 is near instant. The startup is also much quicker.
From memory the first switch to train view was slower than subsequent switches with Qt5.

--

_______________________________________________
Golden-Cheetah-Users mailing list
golden-che...@googlegroups.com
http://groups.google.com/group/golden-cheetah-users?hl=en
---
You received this message because you are subscribed to the Google Groups "golden-cheetah-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golden-cheetah-u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golden-cheetah-users/c08e4c5c-d1dd-4210-bed8-8a40e8ab18fdn%40googlegroups.com.

[Ale Martinez]

Thank you all for the feedback, so we could change default download links to Qt6 builds, Qt5 builds would remain in release page as an option just in case someone needs or prefer them.

[R Bakker]

Dear Golden Cheetah developers, dear users,

I'm a big fan of the program for years and appreciate your work a lot. Not being a programmer or developer myself (but a big fan of analysis and being in control of my own data) I enjoy a lot figuring out the opportunities that Golden Cheetah brings. 

I am a Mac user, specifically MacBook Pro (Nov 2024, M4, Sequoia 15.3.1) and have recently installed v3.7 of GC. I found it to be a bit quicker (changing from Activities to Trends view which took some time normally) and I am looking forward to be able to add photos to activities. However, I did find a very strange mistake in my user charts. See example below, which is a new User chart using template BikeStress series (no changes made). The chart appears to show the side bar and text is mirrored in some way. No data is shown. Other charts works normally.

I have no idea whether this is an issue of my setup (sorry to bother you in that case) or there is a bug in v3.7. Just wanted to let you know. I added Version info FYI.

Best regards,

Richard 

[Ale Martinez]

El sábado, 26 de abril de 2025 a la(s) 6:34:08 p.m. UTC-3, R Bakker escribió:

Dear Golden Cheetah developers, dear users,

I'm a big fan of the program for years and appreciate your work a lot. Not being a programmer or developer myself (but a big fan of analysis and being in control of my own data) I enjoy a lot figuring out the opportunities that Golden Cheetah brings. 

I am a Mac user, specifically MacBook Pro (Nov 2024, M4, Sequoia 15.3.1) and have recently installed v3.7 of GC. I found it to be a bit quicker (changing from Activities to Trends view which took some time normally) and I am looking forward to be able to add photos to activities. However, I did find a very strange mistake in my user charts. See example below, which is a new User chart using template BikeStress series (no changes made). The chart appears to show the side bar and text is mirrored in some way. No data is shown. Other charts works normally.

I have no idea whether this is an issue of my setup (sorry to bother you in that case) or there is a bug in v3.7. Just wanted to let you know. I added Version info FYI.

Something similar was reported by a user last year (https://groups.google.com/g/golden-cheetah-users/c/DXEnOemY24Q/m/I8bAU6u7AAAJ), NFI about the cause.

 

Best regards,

Richard 

Perhaps you can try the newer Qt6 build from https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/v3.7 

[R Bakker]

Thanks Ale, I'll try the new Qt6 build and report back. 

Regards, Richard

[Ale Martinez]

El miércoles, 16 de abril de 2025 a la(s) 7:36:39 p.m. UTC-3, Ale Martinez escribió:

El lunes, 14 de abril de 2025 a la(s) 4:58:09 a.m. UTC-3, Joachim Kohlhammer escribió:

Ale Martinez schrieb am Sonntag, 13. April 2025 um 20:50:40 UTC+2:

I tried both dmg on an ARM64 MacBook running latest Sequoia (15.4) and after mount neither allowed to copy the package or run from there, but results were different:

• For the x64 version I could cp -r /Volumes/GoldenCheetah to the local file system and run from there successfully.
  
• For the ARM64 version nothing worked, macOS message is the package is damaged but the kill 9 is similar to what I got with my local build running stand alone, so it seems code signing failure is the problem here too.

 I think we need to figure out how to sign the code since newer macOS seems to be increasingly restrictive otherwise.

Thanks for trying out! I  agree that finding a solution for signing and even more importantly notarizing the code is the most important topic for now.

My priorities are as follows:

1. Rudimentary Build (x86 + arm64) - done
2. Signing + Notarizing (or how to bypass)
3. Secrets management + injection
4. Adding all required dependencies
5. Preparation for various situations (PR, master, releases)
6. Finetuning

I will try finding out how strict the signing / notarizing rules are and what this means for us. Maybe your proposal with an older xcode-version could be a first step.

It looks like a good plan going forward!

For now I rescued an old Intel MacBook with macOS 12.7 (Monterrey), installed Xcode 14.2, Qt 6.8.3 and the rest of dependencies and generated a dmg

I could reproduce this on AppVeyor but using their preinstalled Qt 6.5.3 to reduce build time it seems to be ok, so we have a replacement for ci builds after Travis-ci deprecated macOS support, details in https://github.com/GoldenCheetah/GoldenCheetah/blob/master/appveyor.yml and https://github.com/GoldenCheetah/GoldenCheetah/tree/master/appveyor/macos for anyone interested. 

[BK]

I have had the same issue with a M1 MacBook Pro running Sequoia 15.4.1. Both the ODPM and WKO4 charts were messed up (flipped interface within the interface). Running the GC version with QT 6xx cleared that problem. A discussion with CHATGPT pointed to these issues:

 ✅ What You’re Seeing

Your screenshot shows Golden Cheetah rendering a flipped and mirrored duplicate of the entire interface inside its own OpenGL context. This kind of visual glitch typically means:

• There’s a GPU texture buffer or framebuffer object (FBO) that is being drawn twice — once normally, once mirrored.

• It often happens when:

  • OpenGL context isn’t fully cleared between frames.

  • A chart redraw calls glCopyTexImage2D or similar functions without the correct viewport or matrix transforms reset.

---

🔥 Known Issues

Golden Cheetah has had OpenGL/Qt rendering issues in the past, especially:

• On macOS with Retina displays (because of HiDPI scaling bugs).

• When using external monitors (especially rotated ones).

• After macOS 12 and later, where Qt’s rendering pipeline changed.

This bug might only show on certain charts because:

• Some charts use custom QPainter/GL hybrid rendering.

• Others might not fully reset the OpenGL matrix stack after drawing.

• GC might be reusing FBOs between chart widgets.

[Ale Martinez]

El sábado, 3 de mayo de 2025 a la(s) 10:52:37 a.m. UTC-3, BK escribió:

I have had the same issue with a M1 MacBook Pro running Sequoia 15.4.1. Both the ODPM and WKO4 charts were messed up (flipped interface within the interface). Running the GC version with QT 6xx cleared that problem.

Than you for the feedback, very useful. I will make the Qt builds the default download from https://www.goldencheetah.org/ to avoid issues for new users.

[R Bakker]

Dear Ale, dear Golden Cheetah Users,

Quick update from my side. I tested v3.7 (Qt5) on my older Macbook Pro (mid 2015, Montery 12.7.8) and gave the same "mirrored" view on my user charts as I reported on April 26th. Upgrading to v3.7 Qt6 did the trick and user charts are normal again. Then tried the same on Macbook Pro (Nov 2024, Sequoia 15.4.1) and no mirrored user charts. Problem solved. Thanks for your time !  

Richard

[R Bakker]

Dear all, 

Another issue popped up: both the media and videosync panes are missing in the side bar of the Train view. Also the buttons at the bottom of the sidebar are missing. Any ideas ? (GC v3.7 Qt6; MacBook Pro Nov 2024, M4, Sequoia 15.3.1)

Thanks, Richard

[Ale Martinez]

El miércoles, 7 de mayo de 2025 a la(s) 12:31:44 p.m. UTC-3, R Bakker escribió:

Dear all, 

Another issue popped up: both the media and videosync panes are missing in the side bar of the Train view. Also the buttons at the bottom of the sidebar are missing. Any ideas ? (GC v3.7 Qt6; MacBook Pro Nov 2024, M4, Sequoia 15.3.1)

I made a configuration mistake in that build (defined both GC_VIDEO_QT6 and GC_VIDEO_NONE in https://github.com/GoldenCheetah/GoldenCheetah/blob/8f03a19473925b5e942ce960cfdb17241710e137/src/gcconfig.pri.in#L245-L249)

Hopefully it is fixed in the one I just uploaded to https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/v3.7 

Thank you for testing and reporting.

[R Bakker]

Thanks Ale,

Works ! Very happy with the new functions in the Trainer and looking forward to try out the new charts. All the best to you and the Golden Cheetah community.

Richard

[mondoshiwan]

i just realized that in the German Localization the *Bearbeiten* (Edit) Menu is missing…

switching to English Language in Preferences then the Edit Menu is there.

Carsten

[Ale Martinez]

El domingo, 18 de mayo de 2025 a la(s) 7:11:44 a.m. UTC-3, mondoshiwan escribió:

i just realized that in the German Localization the *Bearbeiten* (Edit) Menu is missing…

switching to English Language in Preferences then the Edit Menu is there.

In which build: Qt5, Qt6, both? 

[mondoshiwan]

at least in the last snapshot build qt6.

didn't check yet if the qt5 is affected too.

[Ale Martinez]

El domingo, 18 de mayo de 2025 a la(s) 10:27:41 a.m. UTC-3, mondoshiwan escribió:

at least in the last snapshot build qt6.

didn't check yet if the qt5 is affected too.

Thank you. BTW, translation files testing can be accomplished without rebuild as explained in https://github.com/GoldenCheetah/GoldenCheetah/wiki/Guidelines-for-translators 

[mondoshiwan]

Hi Ale,

just tested the stable 3.7 Qt6 MacOS build, it's affected too. And it's not only the German Localiztation, it seems every other language except the english one has no Edit Menu. I tested French, Italian & Spain.

Thx for the Translation Guideline. A few days ago i found a wrong written word… only a *n* is missing.
It's in line 11823 … *Aufzeichung* (Recording) should be > *Aufzeichnung*.
Fixed it with an simple text editor. File is attached

[Ale Martinez]

El lunes, 19 de mayo de 2025 a la(s) 5:29:53 a.m. UTC-3, mondoshiwan escribió:

Hi Ale,

just tested the stable 3.7 Qt6 MacOS build, it's affected too. And it's not only the German Localiztation, it seems every other language except the english one has no Edit Menu. I tested French, Italian & Spain.

I could reproduce on Sequoia macOS and it doesn't seem a translation problem (I verified "Edit" translations are ok at runtime just before to create the menu), but a macOS "feature".

When GC is in English several macOS specific menu items are added at the top of Edit menu and Enter Full Screen item to View menu, neither of this are present when GC is translated.

I tried to set the language for GC on macOS setting but it doesn't recognize it as having other languages, so it seems the application should informs macOS the languages it supports...

 

Thx for the Translation Guideline. A few days ago i found a wrong written word… only a *n* is missing.
It's in line 11823 … *Aufzeichung* (Recording) should be > *Aufzeichnung*.
Fixed it with an simple text editor. File is attached

Thank you, it occurs in other text too, so I would change both:

diff --git a/src/Resources/translations/gc_de.ts b/src/Resources/translations/gc_de.ts
index 2644627f1..8bf9b4609 100644
--- a/src/Resources/translations/gc_de.ts
+++ b/src/Resources/translations/gc_de.ts
@@ -11820,7 +11820,7 @@ Im Allgemeinen sind die H<C3><B6>hendaten am st<C3><A4>rksten und erfordern den h<C3><B6>chsten
Gr
     <message>
         <location filename="../../FileIO/FixGaps.cpp" line="103"/>
         <source>Fix Gaps in Recording</source>
-        <translation>L<C3><BC>cken in Aufzeichung korrigieren</translation>
+        <translation>L<C3><BC>cken in Aufzeichnung korrigieren</translation>
     </message>
     <message>
         <location filename="../../FileIO/FixGaps.cpp" line="115"/>
@@ -14850,7 +14850,7 @@ Drehmomentkorrektur - Der absolute Korrekturwert in Nm (oder Pfund pro Quadratin
     <message>
         <location filename="../../Gui/HelpWhatsThis.cpp" line="168"/>
         <source>Fix Gaps in Recording</source>
-        <translation>Korrigiert L<C3><BC>cken in der Aufzeichung</translation>
+        <translation>Korrigiert L<C3><BC>cken in der Aufzeichnung</translation>
     </message>
     <message>

         <location filename="../../Gui/HelpWhatsThis.cpp" line="170"/> 

[Ale Martinez]

El lunes, 19 de mayo de 2025 a la(s) 6:08:43 p.m. UTC-3, Ale Martinez escribió:

El lunes, 19 de mayo de 2025 a la(s) 5:29:53 a.m. UTC-3, mondoshiwan escribió:

Hi Ale,

just tested the stable 3.7 Qt6 MacOS build, it's affected too. And it's not only the German Localiztation, it seems every other language except the english one has no Edit Menu. I tested French, Italian & Spain.

I could reproduce on Sequoia macOS and it doesn't seem a translation problem (I verified "Edit" translations are ok at runtime just before to create the menu), but a macOS "feature".

When GC is in English several macOS specific menu items are added at the top of Edit menu and Enter Full Screen item to View menu, neither of this are present when GC is translated.

Behavior is similar using the Qt5 build and it happens on macOS Monterey too, so it is unlikely this is new or specific for v3.7

[Ale Martinez]

I created a GitHub issue (https://github.com/GoldenCheetah/GoldenCheetah/issues/4647) for tracking this and, ideally to recibe some contribution from macOS experts, TBH macOS is currently the worst case for GoldenCheetah maintenance at this moment, by far.

[mondoshiwan]

Ale, you wrote that behavior of the qt5 build is similar, but this qt5 Version (build date end of march) has an edit menu with the other languages at least on MacOs 13.7

[Ale Martinez]

El domingo, 25 de mayo de 2025 a la(s) 5:41:01 a.m. UTC-3, mondoshiwan escribió:

Ale, you wrote that behavior of the qt5 build is similar, but this qt5 Version (build date end of march) has an edit menu with the other languages at least on MacOs 13.7

Yes, since I tested on macOS 15.7 using Qt5 build from v3.7 release page and the problem is present too in my minimal test.