Plan View

[Joachim Kohlhammer]

After an initial look at the plan view (PR #4690), I want to share my impressions (user standpoint only, no code review):

• Overall I liked the solution, some refinements could improve the UX.
• Seasons work as expected: Switching in plan view reflects in trends and the other way round
• Forward / backward buttons work as expected
• Sidebar / Charts pane: Is it possible to hide the charts? They don't make sense to me in the plan view
• Toolbar: Currently plan view has no compare pane available, is it possible to disable the toggle action?

Lets start a discussion about trends and plan view. What is the purpose of each, how do they differ, which charts should be available? Based on those results it will be clearer for everybody what to expect where.

Additional proposals (possible tasks for me):

• "Planning Calendar" should be renamed to just "Calendar". I added the planning-attribute as the old calendar still was around when I started
• Agenda should be moved out of the calendar chart into its own. Calendar fits IMHO to both trends and plan, agenda only to plan. The refactoring and code duplication shouldn't be too bad and I would prefer it this way from a users perspective
• Should the current season be shown in the header of the calendar (similar to the agenda)? This would make clearer what the users sees and interacts with while saving the space for the sidebar

Cheers, Joachim

[Paul J]

Joachim,  thank you opening this discussion on the planning view.

Happy to look at:

• Sidebar / Charts pane: Is it possible to hide the charts in plan view?

• Toolbar: Currently plan view has no compare pane available, is it possible to disable the toggle action?

I'm thinking trends is about analysis of completed/past activities and long term metrics, while plan view is about planning future activities, comparing completed activities against the planned training programme. It would be the place to create/edit future activities/training plans, load/save, etc. I'm not sure what metrics would be useful for planned against completed activity comparisons. The  "Planning Calendar" would be the main chart within plan view, and only available in plan view.

[Poncho]

Hi Joachim

I really like the new calendar, thanks for implementing it :)

One little annoyance that I've notice:

* when the calendar is used as default view and is opened immediately
after program start, new activities autoimported in the background only
appear after switching to another view.
For me it would be convenient if a successful autoimport would refresh
the calendar automatically.

Best regards,
Poncho

On 11/15/25 16:45, Joachim Kohlhammer wrote:
> After an initial look at the plan view (PR #4690), I want to share my
> impressions (user standpoint only, no code review):
>

> - Overall I liked the solution, some refinements could improve the UX.
> - Seasons work as expected: Switching in plan view reflects in trends

> and the other way round

> - Forward / backward buttons work as expected
> - Sidebar / Charts pane: Is it possible to hide the charts? They don't

> make sense to me in the plan view

> - Toolbar: Currently plan view has no compare pane available, is it

> possible to disable the toggle action?
>
>
> Lets start a discussion about trends and plan view. What is the purpose of
> each, how do they differ, which charts should be available? Based on those
> results it will be clearer for everybody what to expect where.
>
> Additional proposals (possible tasks for me):
>

> - "Planning Calendar" should be renamed to just "Calendar". I added the

> planning-attribute as the old calendar still was around when I started

> - Agenda should be moved out of the calendar chart into its own.

> Calendar fits IMHO to both trends and plan, agenda only to plan. The
> refactoring and code duplication shouldn't be too bad and I would prefer it
> this way from a users perspective

> - Should the current season be shown in the header of the calendar

[Joachim Kohlhammer]

Paul J schrieb am Samstag, 15. November 2025 um 20:20:54 UTC+1:

I'm thinking trends is about analysis of completed/past activities and long term metrics, while plan view is about planning future activities, comparing completed activities against the planned training programme. It would be the place to create/edit future activities/training plans, load/save, etc. I'm not sure what metrics would be useful for planned against completed activity comparisons. The  "Planning Calendar" would be the main chart within plan view, and only available in plan view.

I fully agree with you on trends view, mostly on plan view. Plan view is for

• creating (calendar + Marks proposal for a long term plan: https://github.com/GoldenCheetah/GoldenCheetah/blob/master/doc/design/planning-UX.jpg)
• executing (agenda)
• monitoring (not yet defined view, maybe showing load / time deviations, missed or out of plan activities)

Nevertheless I would keep the calendar also available in the trends view (without agenda) as it shows an overview of your past activities, even if you don't follow a plan

[Joachim Kohlhammer]

Poncho schrieb am Samstag, 15. November 2025 um 20:33:37 UTC+1:

* when the calendar is used as default view and is opened immediately
after program start, new activities autoimported in the background only
appear after switching to another view.
For me it would be convenient if a successful autoimport would refresh
the calendar automatically.

This is not related to the calendar but happens if you import before the activities view was loaded (see https://github.com/GoldenCheetah/GoldenCheetah/blob/a7200a31ff54f1f8a9cc8bf765fe699a02654638/src/Gui/AthleteTab.cpp#L209). @Paul, do you have an idea to cleanly fix this? I like the lazy loading approach, but here it comes at a price

[Paul J]

Hi Joachim, I'll take a look at the Plan view auto import issue.

[Paul J]

The auto import not updating the calendar is probably due to the import containing more than 20 activities  ( Poncho can you confirm this is the issue? or provide more information on how to repeat the issue? )  , as I have tested it with fewer activities and it updates fine, as each activity is added it is updated in the calendar

The issue is trying to import >20 activities, which RideImportWizard.cpp considers to be a batch import and then it doesn't signal in the RideCache that a ride has been added, see  https://github.com/GoldenCheetah/GoldenCheetah/blob/a7200a31ff54f1f8a9cc8bf765fe699a02654638/src/Gui/RideImportWizard.cpp#L1121  and   https://github.com/GoldenCheetah/GoldenCheetah/blob/a7200a31ff54f1f8a9cc8bf765fe699a02654638/src/Core/RideCache.cpp#L302

I have created commit that will add a signal when the ride import is complete and used this to refresh the calendar, it works fine, I can it to the plan view work once Poncho has confirmed this is actually the issue.

[Ale Martinez]

El sábado, 15 de noviembre de 2025 a la(s) 12:45:11 p.m. UTC-3, tiefgara...@gmail.com escribió:

After an initial look at the plan view (PR #4690), I want to share my impressions (user standpoint only, no code review):

• Overall I liked the solution, some refinements could improve the UX.
• Seasons work as expected: Switching in plan view reflects in trends and the other way round
• Forward / backward buttons work as expected
• Sidebar / Charts pane: Is it possible to hide the charts? They don't make sense to me in the plan view
• Toolbar: Currently plan view has no compare pane available, is it possible to disable the toggle action?

Mostly agree, on Windows there is a weird behavior when the current chart is PMC on Trends: the sidebar disappears and then comes back, which is awful.

WRT compare button we could do something similar to perspective selector to disable or hide when not available s.t. Athletes View too.

 

Lets start a discussion about trends and plan view. What is the purpose of each, how do they differ, which charts should be available? Based on those results it will be clearer for everybody what to expect where.

Additional proposals (possible tasks for me):

• "Planning Calendar" should be renamed to just "Calendar". I added the planning-attribute as the old calendar still was around when I started
• Agenda should be moved out of the calendar chart into its own. Calendar fits IMHO to both trends and plan, agenda only to plan. The refactoring and code duplication shouldn't be too bad and I would prefer it this way from a users perspective
• Should the current season be shown in the header of the calendar (similar to the agenda)? This would make clearer what the users sees and interacts with while saving the space for the sidebar

Agree, my initial concern in the current status is Plan View is not different than a Plan perspective on Trends -except for the direct access via scope bar/view menu.

PS: if anyone else not building from source want to give this a try, here is a Windows installer for latest snapshot with this PR applied https://temp.sh/asGRY/GoldenCheetah_v3.7_x64Qt6.exe, for macOS and Linux go to the Artifacts tab for the OS in https://ci.appveyor.com/project/Joern-R/goldencheetah-knhd8/builds/53083643

[Ale Martinez]

El domingo, 16 de noviembre de 2025 a la(s) 1:11:11 p.m. UTC-3, paulj...@gmail.com escribió:

The auto import not updating the calendar is probably due to the import containing more than 20 activities  ( Poncho can you confirm this is the issue? or provide more information on how to repeat the issue? )  , as I have tested it with fewer activities and it updates fine, as each activity is added it is updated in the calendar

The issue is trying to import >20 activities, which RideImportWizard.cpp considers to be a batch import and then it doesn't signal in the RideCache that a ride has been added, see  https://github.com/GoldenCheetah/GoldenCheetah/blob/a7200a31ff54f1f8a9cc8bf765fe699a02654638/src/Gui/RideImportWizard.cpp#L1121  and   https://github.com/GoldenCheetah/GoldenCheetah/blob/a7200a31ff54f1f8a9cc8bf765fe699a02654638/src/Core/RideCache.cpp#L302

I have created commit that will add a signal when the ride import is complete and used this to refresh the calendar, it works fine, I can it to the plan view work once Poncho has confirmed this is actually the issue.

Please don't, since this is an independent issue of Plan view and present in current master, let's make a separate PR. 

[Paul J]

Auto import not updating the calendar changes now in a separate PR #7434

[Paul J]

I'll take a look at:  Windows there is a weird behavior when the current chart is PMC on Trends: the sidebar disappears and then comes back, which is awful.

[Paul J]

I'm not sure why the PMC chart should cause any left sidebar issues, but I have corrected the  LTM sidebar status displayed in the View menu and updated its status on change:
https://github.com/GoldenCheetah/GoldenCheetah/pull/4690/commits/3ed4442e505e49443eb4366e73f489e300f51c1c

If it still occurs, can you explain the steps to repeat it?

[Ale Martinez]

El domingo, 16 de noviembre de 2025 a la(s) 3:28:07 p.m. UTC-3, paulj...@gmail.com escribió:

I'm not sure why the PMC chart should cause any left sidebar issues, but I have corrected the  LTM sidebar status displayed in the View menu and updated its status on change:
https://github.com/GoldenCheetah/GoldenCheetah/pull/4690/commits/3ed4442e505e49443eb4366e73f489e300f51c1c

If it still occurs, can you explain the steps to repeat it?

Yes, still happens.

The steps are to go back and forth between Trends and Plan using the scope bar, when the current chart in Trends view is the new Calendar, an Overview or a User chart the transition is smooth, but when the current chart in Trends is a Metrics Trends (s.t. PMC) or an R chart there is an awful flicker on the left sidebar, only tested on Windows 11 with Qt 6.8.3 for now.

[Paul J]

I see it now, thank you the explanation,  I guess that the metrics chart is being drawn before the sidebar is attached on the viewChanged() event and the layout widgets resize, as I see the axis line very briefly over the sidebar area causing the flicker, I'll look at fixing this.

[Paul J]

Please see (and test) the following commit which removes the user chart trends-plan view switching:  https://github.com/GoldenCheetah/GoldenCheetah/pull/4690/commits/c4bf7485f97b6798340ad350d2318db74923106f

[Ale Martinez]

El domingo, 16 de noviembre de 2025 a la(s) 8:29:41 p.m. UTC-3, paulj...@gmail.com escribió:

Please see (and test) the following commit which removes the user chart trends-plan view switching:  https://github.com/GoldenCheetah/GoldenCheetah/pull/4690/commits/c4bf7485f97b6798340ad350d2318db74923106f

That fixes the flicker, thank you! 

[Pat Voi]

Hello Joachim, one small detail I noticed:
Would it be possible to include a checkbox to classify an activity as a non-activity, for example for recovery time, in order to follow a precise plan. thank you!

Pat

[Joachim Kohlhammer]

Hi Pat,

I am not aware of any such flag in the ride items. To skip summary, probably a deeper change would be necessary. Therefore I don't have this on my list at the moment. But your proposal on Recovery_Time has a high priority for me (1. extract the agenda into its own chart, 2. Connect planned and completed activities, 3. Recovery_time), but will most probably only be visible in day and week view. But maybe we could give a hint in the plan activity dialog: "take care of recovery" or something similar.

Cheers, Joachim

[Ale Martinez]

El lunes, 17 de noviembre de 2025 a la(s) 12:07:14 p.m. UTC-3, voip...@gmail.com escribió:

Hello Joachim, one small detail I noticed:
Would it be possible to include a checkbox to classify an activity as a non-activity, for example for recovery time, in order to follow a precise plan. thank you!

Pat

You can add Recovery as an additional Sport (or as an additional Recovery bool Data Field), after that you can define your own Activities User Metric to skip counting them as normal activities, something like { value(Sport="Recovery" ? 0 : 1); } should work, and use Sport<>"Recovery" as a filter in Trends perspectives when you want to avoid them in charts.

I think it is overkill, but you can do that if you like to.

[Joachim Kohlhammer]

Hi Pat,

Your proposal on Recovery_Time is still on my list (1. extract the agenda into its own chart, 2. Connect planned and completed activities, 3. Recovery_time), most probably visible in day and week view. But maybe we could give a hint in the plan activity dialog: "pay attention to your recovery" or something similar.

Cheers, Joachim

[Pat Voi]

Hi Joachim,

 1. extract the agenda into its own chart,

-  That's a good idea, if it's possible.

 2. Connect planned and completed activities,

-  I also believe that planned and carried out activities should be linked.

3. Recovery_time), most probably visible in day and week view. 

-  To ensure optimal monitoring, it would be wise to indicate the recovery time per day, week and month.

But maybe we could give a hint in the plan activity dialog: "pay attention to your recovery" or something similar.

- It seems to me that the 'recovery time' is really good!

From my perspective as a user, it seems to me that there are two alternatives for 'recovery time' in order to define the recovery time using RPE zones.

- Zone 0: Recovery time should not be counted towards activities.
- Zone 1 and above: Recovery time is included in activities.

Pat

[Pat Voi]

Hi Ale,

Unless I'm mistaken in my tests, "recovery time" is always counted in activities.
 
Pat

[Paul J]

I'm not sure whether we need to link planned activities to completed activities, I'd guess that a useful chart would be the planned training "load" per day/week against the actual load, so that it is possible to see how closely the plan is being followed. I have put "load" in quotes as I guess there many metrics that might be considered for comparison.

[Poncho]

On 11/16/25 17:11, Paul J wrote:
> The auto import not updating the calendar is probably due to the import
> containing more than 20 activities

It was less than 20 activities for sure. But when I've tried today, I
couldn't reproduce the issue with current git master.

I'll do some better debugging in case it happens again.

[Ale Martinez]

El miércoles, 19 de noviembre de 2025 a la(s) 3:38:58 p.m. UTC-3, voip...@gmail.com escribió:

Hi Ale,

Unless I'm mistaken in my tests, "recovery time" is always counted in activities.

All activities are counted by the builtin metric off course, that's the reason I suggested you define your own User Metric to skip the fake activities used for that purpose, (re)read my previous message. 

[Paul J]

   To make the Plan View distinct from the trends view I think we need to consider restricting which charts are only available in each view ?

   

  Currently the plan view PR 4690  supports all trends view charts in the plan view, except for the Overview and UserChart which use the OverViewScope enumeration to tailor their behaviour,

  so there are plan view specific versions of these charts in the following commit. But if the Overview and UserChart are not required in plan view, then this commit can be reverted, and the additional

  OverviewPlan, OverviewPlanBlank and UserPlan chart types can be removed.

 The current allocations are (analysis only charts have been omitted):

    // name                     GcWinID
    { VIEW_TRENDS, tr("Season Overview"),GcWindowTypes::OverviewTrends },
    { VIEW_TRENDS, tr("Blank Overview "),GcWindowTypes::OverviewTrendsBlank },
    { VIEW_PLAN, tr("Plan Overview"),GcWindowTypes::OverviewPlan },
    { VIEW_PLAN, tr("Blank Overview "),GcWindowTypes::OverviewPlanBlank },
    { VIEW_TRENDS, tr("User Chart"),GcWindowTypes::UserTrends },
    { VIEW_PLAN, tr("User Chart"),GcWindowTypes::UserPlan },

    { VIEW_TRENDS|VIEW_PLAN, tr("Trends"),GcWindowTypes::LTM },
    { VIEW_TRENDS|VIEW_PLAN, tr("TreeMap"),GcWindowTypes::TreeMap },
    { VIEW_TRENDS|VIEW_PLAN,  tr("Power Duration "),GcWindowTypes::CriticalPowerSummary },
    { VIEW_TRENDS|VIEW_PLAN, tr("Distribution"),GcWindowTypes::Distribution },
    { VIEW_TRENDS, tr("R Chart "),GcWindowTypes::RConsoleSeason },
    { VIEW_TRENDS, tr("Python Chart "),GcWindowTypes::PythonSeason },
    { VIEW_TRENDS|VIEW_PLAN, tr("Navigator"), GcWindowTypes::ActivityNavigator },
    { VIEW_ANALYSIS|VIEW_TRENDS|VIEW_TRAIN, tr("Web page"),GcWindowTypes::WebPageWindow }, 
    { VIEW_TRENDS|VIEW_PLAN, tr("Calendar"),GcWindowTypes::Calendar },

On Sunday, 16 November 2025 at 16:22:27 UTC Ale Martinez wrote:

[Ale Martinez]

I forgot to answer to this, IMO the Plan view should allow charts related to the planning process, which includes evaluating interactively how the plan impacts on training load, training intensity distribution, etc. so necessarily there will be some overlap and "programable" charts should be enable to give the users the flexibility to create the ones they like.

[Paul J]

PR #4690 supports the overlap of charts (all trends charts are available) and your reply answers the only remaining question I had, so I think unless there are anymore reported issues its now complete.

[Ale Martinez]

El sábado, 6 de diciembre de 2025 a la(s) 3:53:09 p.m. UTC-3, paulj...@gmail.com escribió:

PR #4690 supports the overlap of charts (all trends charts are available) and your reply answers the only remaining question I had, so I think unless there are anymore reported issues its now complete.

Paul's work on Plan View is included in latest snapshot builds: https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/snapshot, feedback is welcome. 

[Joachim Kohlhammer]

Ale Martinez schrieb am Sonntag, 14. Dezember 2025 um 17:58:14 UTC+1:

Paul's work on Plan View is included in latest snapshot builds: https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/snapshot, feedback is welcome. 

Current master contains a bug that can crash when removing a calendar and switching time ranges afterwards. This is only related to the calendar, not Pauls work. https://github.com/GoldenCheetah/GoldenCheetah/pull/4759 implements a fix

[Poncho]

I think the issue is triggered by deleting the imports directory in
~/.goldencheetah/$USER/

I did this before backing up my profile (I keep my fitfiles elsewhere, I
don't need that directory). Afterwards, the single new activity
imported by autoimport didn't update in the calendar view.

Certainly a minor issue if it only happens when a user messes with their
profile directory.

[Ale Martinez]

El martes, 30 de diciembre de 2025 a la(s) 1:48:15 p.m. UTC-3, Poncho escribió:

I think the issue is triggered by deleting the imports directory in
~/.goldencheetah/$USER/

I did this before backing up my profile (I keep my fitfiles elsewhere, I
don't need that directory). Afterwards, the single new activity
imported by autoimport didn't update in the calendar view.

I am not sure if it is related but, from v3.6 we use the imports folder to check for already imported files during auto-import, to avoid parsing the same files again and again, and to avoid deleted activities being recreated.

[Ale Martinez]

El martes, 30 de diciembre de 2025 a la(s) 4:22:08 p.m. UTC-3, Ale Martinez escribió:

El martes, 30 de diciembre de 2025 a la(s) 1:48:15 p.m. UTC-3, Poncho escribió:

I think the issue is triggered by deleting the imports directory in
~/.goldencheetah/$USER/

I did this before backing up my profile (I keep my fitfiles elsewhere, I
don't need that directory). Afterwards, the single new activity
imported by autoimport didn't update in the calendar view.

I am not sure if it is related but, from v3.6 we use the imports folder to check for already imported files during auto-import, to avoid parsing the same files again and again, and to avoid deleted activities being recreated.

This PR: https://github.com/GoldenCheetah/GoldenCheetah/pull/4347 

[Paul J]

I'm also seeing this problem, I auto import in the background from my master files on a separate drive (last 90 days), and a PR/patch (https://github.com/paulj49457/GoldenCheetah/tree/shared-application-options-pack) clears my import folder every time GC is closed, to prevent storage duplication.

So I now understand that I'm actually importing >20 files every time GC starts (in the background), and the import process it detects I already have an activity with the same date/time and discards it, But as I have more than 20 files the ride update event doesn't occur, so any new activities are not displayed in the calendar until there is another update event, like switching to analysis and then returning to plan view.

So given that GC doesn't expect the user to be clearing the import folder, should we consider supporting it? And use the fix in https://github.com/GoldenCheetah/GoldenCheetah/pull/4734 ?

[Joachim Kohlhammer]

I will have a look into the missing update of the calendar. At the moment I am fighting with moved activities outside the calendar (mainly MetadataWindow) to save both actual and linked activity. PR #4772 will be updated soon with both changes. BTW: If I could change only one thing about Golden Cheetah - that clearly would be the mutable filenames containing date and time of activities.

[Joachim Kohlhammer]

Joachim Kohlhammer schrieb am Donnerstag, 1. Januar 2026 um 09:17:40 UTC+1:

I will have a look into the missing update of the calendar. At the moment I am fighting with moved activities outside the calendar (mainly MetadataWindow) to save both actual and linked activity. PR #4772 will be updated soon with both changes. BTW: If I could change only one thing about Golden Cheetah - that clearly would be the mutable filenames containing date and time of activities.

The calendar relies on the signal Context::rideAdded to update. This signal is suppressed in RideImportWizard when importing more than 20 items. I never experienced this behaviour as my autoimport usually is below 5 activities a time.

Is it ok to add a new signal Context::batchImportFinished as an alternative to the single rideAdded-signals? This would be emitted by RideImportWizard after the import of more than 20 activities finished (successful or with errors, these numbers could be parameters to the signal).

[Paul J]

Please see https://github.com/GoldenCheetah/GoldenCheetah/pull/4734 , its the same idea, but it wasn't understood (at the time) that it is required for those who clear their import folder.

[Joachim Kohlhammer]

This looks exactly like what I intended!

[Ale Martinez]

Ok, since there is an agreement I reopened the PR, there are some conflicts to fix now https://github.com/GoldenCheetah/GoldenCheetah/pull/4734

[Paul J]

I have updated the PR

[Joachim Kohlhammer]

Paul J schrieb am Donnerstag, 1. Januar 2026 um 20:07:38 UTC+1:

I have updated the PR

Works just as expected :)

I just pushed a update to PR 4772 (linking of activities). Feedback is highly welcome, probably I missed the one or other path to break consistency. 

[Ale Martinez]

El viernes, 2 de enero de 2026 a la(s) 6:56:09 a.m. UTC-3, tiefgara...@gmail.com escribió:

Paul J schrieb am Donnerstag, 1. Januar 2026 um 20:07:38 UTC+1:

I have updated the PR

Works just as expected :)

The PR is merged and binaries can be downloaded for testing from https://ci.appveyor.com/project/Joern-R/goldencheetah-knhd8/builds/53311731

PS: WRT imports folder cleanup, if the objective is to release disk space an alternative to preserve the performance on import and delete behavior is to truncate the files to zero size instead of removing them.

[Joachim Kohlhammer]

Today I started working on the last calendar-topic on my list for 3.8: Visualizing recovery time. What I got running is some bars in day- and weekview:

To have a commonly accepted version, I need some feedback:

1. Should the recovery always be shown or just as an option? Do really all users want to see this all the time?
2. Currently the recovery is only sown as bars, no tooltip, no visualization in month view. My idea is to keep the bars, but additionally add an icon to the column header (similar to phases and events), including a tooltip: "Recovery from Unnamed Hiking, Ends: 02.07.2025, 19.20" (same title as in the calendar). This icon could even be shown on month view for each day with active recovery
3. Color: Currently I use a dimmed version (alpha: 60) of CPOWER. Is that ok or should I introduce a new GColor-constant? I am unsure what this means for all the themes - and existing installations
4. Recovery time never shifts start- or end-time of a day. This is controlled only be the default settings or activities exceeding this timerange.
5. Lookback is set to 7 days prior to what the calendar shows. So if I had an activity on 28.06. in my example with a recovery of 2 days, a bar without activity would be shown on 30.6. 

Based on what I could find out, Garmin recalculates the recovery time with each new activity. Based on that, I use the following approach:

1. No recovery before an activity with set recovery time - start that
2. Recovery active before an activity with set recovery time - end previous recovery time and start the new one
3. Recovery active before an activity without set recovery time - ignore this activity and continue recovery time of the previous activity until it ends

Cheers, Joachim

[Rolf Kaul]

Hi Joachim,

I just have some feedback on point 1. Personally, I don't need this recovery time. It isn't predictable for me.

Regards

Rolf

--
_______________________________________________
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/82636c1d-154e-4a38-9cc8-bd9609baea15n%40googlegroups.com.

[Ale Martinez]

El lunes, 19 de enero de 2026 a la(s) 4:06:41 a.m. UTC-3, rolf...@gmail.com escribió:

Hi Joachim,

I just have some feedback on point 1. Personally, I don't need this recovery time. It isn't predictable for me.

Regards

Rolf

I fully agree, the numbers generated by my Garmin(s) are completely useless for mi as a triathlete regularly training around 12 times per week.

[Pat Voi]

Good morning,

My personal opinion: I believe that in amateur and professional sports, whether team or individual, recovery is an essential element in the pursuit of performance, as it always works in conjunction with athletic training. There is no progress without recovery.

1 - The recovery screen should only be displayed as an option.
2 - I think that's good
4 -  I think that's good
5 -   very good
Yes, Garmin recalculates the recovery time for each new activity.

[Mark Liversedge]

The problem here is what is recovered?

Also, the Banister model can help so long as you accept that it is potential performance that is recovered

Mark

[Pat Voi]

Good Morning Mark,
I agree, recovery mode can be useful. Would it be possible for Joachim to make the display of recovery mode optional, so that each user can choose whether or not to enable it?

[Ale Martinez]

I think to consider recovered as on/off is too simplistic to be useful and it is more likely misleading, for example If I did an interval run at 5k pace in the morning I may take me 3 days or more to be recovered enough for a similar stimulus, but a recovery swim in the afternoon and an endurance ride/run the next day can be perfectly reasonable.

[Joachim Kohlhammer]

Looks like my plan is way too shortsighted. I will stop on this topic until we have a better concept. Thanks for all your feedback!

[marcen]

Hello, I have been using the plan view for some time now.

Here is my feedback.

1. Batch processing shows planned and completed activities. It is difficult to select the right activity. The planned activity always shows an error when exporting.

2. How can I use the "repeat schedule..." to copy a planned week 1:1 into a new week? Unfortunately, I was unable to do this.

4. The copy function for individual activities works very well.

Possible enhancements to the "Plan activity...". function:
1. It would be helpful to have the "workout code" available in "Plan activity...".
2. Once the activity has been planned, would it be possible to use the "Plan activity..." to adjust the activity?

Suggestions for enhancements to the planning view:
1. Events and phases with dates and names available for diagrams. It would be nice if the tiles were also editable to make it easier to adjust the phases.
Here is a picture of how I have implemented it in GC so far to create a macro plan. The tiles in the first row would then be phases that can be edited, making it easier to plan your blocks or edit.

2. A diagram with the option to enter text, perhaps also to create a table view. For macro planning.

[Joachim Kohlhammer]

Hi Marcen,

thanks for your feedback. Your comments read as most of the features work as expected :)

You can find my replies inline below your comments

Did you also use the agenda? I like it a lot but would be happy to get some feedback. Ale just merged the plan adherence chart. My intention for it is to retrospectively analyze how close a plan was followed, not from a PMC view but pure behaviour. Feedback would be highly appreciated (e.g. should I visualize the phases in this chart?)

Cheers, Joachim

marcen schrieb am Sonntag, 8. März 2026 um 23:59:24 UTC+1:

1. Batch processing shows planned and completed activities. It is difficult to select the right activity. The planned activity always shows an error when exporting.

Didn't test this yet, will look into it

 

2. How can I use the "repeat schedule..." to copy a planned week 1:1 into a new week? Unfortunately, I was unable to do this.

Can you explain if a specific step (1: Repeat Schedule Setup, 2: Repeat Schedule Activities, 3: Repeat Schedule Summary) fails or if the UX is not understandable? From a functional perspective my tests today worked as expected - but I am very interested to understand your issues. Especially as I am planning to implement a "export plan" feature, similar to this wizard.

 

Possible enhancements to the "Plan activity...". function:
1. It would be helpful to have the "workout code" available in "Plan activity...".

Agree, will add it

 

2. Once the activity has been planned, would it be possible to use the "Plan activity..." to adjust the activity?

Sounds like a good idea to me. Let me think about how and what to implement.

 

Suggestions for enhancements to the planning view:

2. A diagram with the option to enter text, perhaps also to create a table view. For macro planning.

Macro planning is on my mid-term list, most probably after the next release. I want to finish the current feature set as good as possible. Mark provided a sketch how a macro planning
dialog / chart could look like, see https://github.com/GoldenCheetah/GoldenCheetah/blob/master/doc/design/planning-UX.jpg. This will be the basis of my implementation.

[marcen]

Hi Joachim,

Thank you for looking at these items.

Regarding the “Plan Activity” function.

It is the first side. I am not clear on how “Repeat Schedule Setup” works.
I have not yet understood how it works with the start and end dates.
I would like to use this function to copy a planned week to the coming week.

My current approach is as follows: I select Monday as the start and Sunday as the end, and then select the Monday in the calendar to which the units should be copied. When I then look at the “Repeat Schedule Summary” pages where the units are copied to, it is not the same day of the week as in my planned week. The next unit is then simply on the next day, but there should be two days off in between. However, I haven't found a setting where I can adjust this. Here is a picture showing what I want to achieve.


I'm also not sure when I should activate the function.


One more note about the calendar and summary. Currently, planned and completed activities appear in the summary, so I have duplicate entries there. For example, if the planned unit is scheduled for one hour and the completed unit also lasted one hour, the summary shows the duration as two hours, even though the actual workload was only one hour. Now I was wondering whether it would make more sense not to include past planned activities from today onwards and only include planned activities that lie in the future. I hope you understand what I mean. What is your opinion on this?

We can take a closer look at the macro planning when it becomes more concrete. My idea was Mark's image in the upper left corner.

I don't use the agenda much at the moment. Just general feedback or something specific?

Regarding the plan adherence chart:
I haven't looked at it in detail yet. I've only looked at the attached image. It's an interesting idea.

It looks like it's just numerical values that indicate the direction in which it was shifted. Without context as to why the unit was shifted, it's difficult for me to deduce what I can do better in the next block. By context, I mean keywords such as “sick,” “injury,” “exhausted,” “lack of time,” or “sleep,” which are then linked to the shifted unit.

[Joachim Kohlhammer]

Hi Marcen,

I just created 4 new PRs:

* https://github.com/GoldenCheetah/GoldenCheetah/pull/4843 - show only certain planned activities in the summary (all, none, upcoming, missed or upcoming), independent on the currently active search

* https://github.com/GoldenCheetah/GoldenCheetah/pull/4842 - allow entering workout code in plan activities just as in log activity

* https://github.com/GoldenCheetah/GoldenCheetah/pull/4840 - fix export in BatchProcessingDialog. I am only partially happy with this PR as it only fixes your specific issue while I am sure there are other dialogs using the same pattern. Additionally I don't see too much sense in exporting planned activities as CSV as those files probably will be empty in most cases

* https://github.com/GoldenCheetah/GoldenCheetah/pull/4841 - independent of your issues but hopefully useful: This allows to duplicate / clone series in the user chart

On your question about identifying activities in the BatchProcessingDialog: Personally I am not a big friend of showing the filenames in the dialog, IMHO those are internal details and it doesn't make identifying activities very easy. Probably using the global filter is the best way to only include those activities in the export you really want to see.

I understood your use case for the repeat schedule functionality - and currently it is not possible. But as already noted: I want to implement an export plan functionality similar to this dialog which would fail the same way. Therefore I have to update the whole dialog and will keep you updated here.

Cheers, Joachim

[marcen]

Hi Joachim, thank you very much for the new PRs.

I’ll test the various PRs in due course.

Regarding BatchProcessingDialog:
That’s a good point about the global filter, thanks.
As the dialog currently stands, the date and time are duplicated. Once in the filename and then again as two separate date and time columns.

Thanks for the clarification and for noting it. I think an export for planned activities could be helpful if a different computer is used for the units than the one used for planning.

[Ale Martinez]

El sábado, 14 de marzo de 2026 a la(s) 12:07:30 p.m. UTC-3, tiefgara...@gmail.com escribió:

I just created 4 new PRs:

* https://github.com/GoldenCheetah/GoldenCheetah/pull/4843 - show only certain planned activities in the summary (all, none, upcoming, missed or upcoming), independent on the currently active search

* https://github.com/GoldenCheetah/GoldenCheetah/pull/4842 - allow entering workout code in plan activities just as in log activity

* https://github.com/GoldenCheetah/GoldenCheetah/pull/4840 - fix export in BatchProcessingDialog. I am only partially happy with this PR as it only fixes your specific issue while I am sure there are other dialogs using the same pattern. Additionally I don't see too much sense in exporting planned activities as CSV as those files probably will be empty in most cases

* https://github.com/GoldenCheetah/GoldenCheetah/pull/4841 - independent of your issues but hopefully useful: This allows to duplicate / clone series in the user chart

Thanks Joachim, Since they seem safe and focused I merged these PRs and triggered snapshot update to make testing easier, later this month we could create a dev build for better documentation. 

[marcen]

Hi Joachim,
I have a question about the user chart. I'm not sure if this is related to change 4841, but when I set a user chart to a bar chart, the bars no longer appear. Could that be related to the change?

[Joachim Kohlhammer]

marcen schrieb am Donnerstag, 19. März 2026 um 11:10:49 UTC+1:

Hi Joachim,
I have a question about the user chart. I'm not sure if this is related to change 4841, but when I set a user chart to a bar chart, the bars no longer appear. Could that be related to the change?

This can very well be the case, probably a side effect of the newly introduced copy constructor or operator=. I will check this weekend

[Joachim Kohlhammer]

You were fully right, my prior PR (4841) caused the issue. Fixed in https://github.com/GoldenCheetah/GoldenCheetah/pull/4848

[marcen]

Thanks a lot, Joachim, for the fix. The bar chart is working again as it did before. The copy function is also working as expected again. I still need some time to test the other PRs.

[Joachim Kohlhammer]

Hi Marcen,

here are my latest updates on the "Repeat Schedule Feature". It is a completely new concept that allows 1-1 copies, removing the automatic conflict handling, insertion of rest days or shifting activities.

I wanted to go into a direction that can best be reused for importing and exporting training plans. It offers four variables:

• Start of the target range is chosen by launching the wizard from the calendar
• Source range
• Should empty days before the first and after the last planned activity be kept or trimmed?
• Which source date to use: The one that was originally used while creating the plan or the one as of now which might include manual shifts (moved on the calendar, inserted rest days)

All planned activities that preexist in the target range will be deleted automatically with the exception of completed planned activities (linked to an actual activity).

Conflict resolution (can arise from conflicting original dates / times (resolvable) and completed planned activities (auto resolved, those always win)) is performed on the - still very rough and ugly looking - second page. This hopefully wont be too much of an issue in real life.

I am highly interested in your feedback: Is this better understandable than the original wizard? Do you consider it useful?

Cheers, Joachim

[marcen]

Hi Joachim,  thank you for sharing your idea with me. Here are my comments and the questions that have come to mind.

About the 4 points

1. Yes, I think it's good that the selected date in the calendar is the start date.
2. No comment
3. I think it should be an option. For example, if 3 weeks are being copied and the last week is a recovery week, it would be helpful if the option to set training rest days could be included. Or in the other case, if a training day should be exactly at the beginning and end.
   1. If I'm not mistaken, you can do that using the option: Include front and back gap days in the range
      1. Suggested text for the option: Include rest days at the beginning and end of the target range.
4. I don't quite understand that point yet. By “original plan,” do you mean what the plan looked like when it was first created?

"All planned activities that preexist in the target range will be deleted automatically with the exception of completed planned activities (linked to an actual activity)."

That’s when it occurred to me that there should perhaps be an option to reschedule planned activities. For example, I might need to postpone a phase because I’m not quite ready with my training after all.
Otherwise, though, I think it’s fine that unlinked planned activities are deleted. I can always reschedule them manually beforehand.

Regarding the second page. Maybe a note on what the conflict is, so I can resolve it manually before I start the wizard. I don't have a strong opinion on the design. For a consistent look, maybe something like what's shown in the image.

Back to the first page. If “trage ragen” is my new date range—the one I’ll be copying the scheduled activities into—I think it would be better if it appeared right below “Copy from.” That makes it easier to identify. I would replace “trage ragen” with “Start new schedule from DATE to DATE.”

I find this draft easier to understand than the first one. Maybe another GC user would like to share their thoughts on it.

[Ale Martinez]

El lunes, 23 de marzo de 2026 a la(s) 7:46:23 p.m. UTC-3, marcen escribió:

1. I don't quite understand that point yet. By “original plan,” do you mean what the plan looked like when it was first created?

This may help: https://github.com/GoldenCheetah/GoldenCheetah/pull/4822#issuecomment-3861511970 

[Joachim Kohlhammer]

Hi Marcen,

nice to see we are on the same page. I also like this approach better than my original one.

I see the deletion the same as you: Better cleanup beforehand than adding complicated logic. Also I don't expect that the repeat schedule functionality will be used often to copy into a date range with preexisting planned activities.

You are also right on the checkbox "Include front and back gap days in target range": This allows to trim rest days from the front and back.

On the original dates: The PR Ale referenced does exactly what you assume: When using drag & drop or "insert / delete rest day" in the calendar, the original date is stored in the planned activity. This date wont be overwritten in subsequent operations. Only copying it clears that date. This allows to copy according to the original intent.

I will continue with the functional implementation, afterwards we can update the texts (not my biggest strength), layout and default values.

Cheers, Joachim

[marcen]

Thanks, Ale, for the link. That makes it clear to me how it works.

Thank you Joachim for the explanation and for taking the time. I think both cases have their justification in terms of how a plan should be repeated. Yes, we can discuss different versions of the texts, layout, and default values later.

Regarding the other PRs—4843, 4842, and 4840 — they work as they should for me.

[Joachim Kohlhammer]

Finally I was able to bring the PR into a state where I am happy with it: https://github.com/GoldenCheetah/GoldenCheetah/pull/4850

Feedback is highly appreciated, especially on: does it work at all, does it what it should, is something important missing, are the labels understandable and descriptive, are the defaults sensible.

Cheers, Joachim