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.