With Project Libre being open source, I asked Claude to find how I might change the code to correct this issue tha I perceived as an error. Here’s my prompt and Claude’s response, which indicated that the code does not refresh when I change the date in the calendar. I don’t know Java, but retired I may try to implement the changes Clause suggests. My hope, though, is that Project Libre corrects this, as it really degrades my colleagues view of project Libre when I have to shut down and restart after I make calendar changes.
Claude summarizes: The bug, in short
Editing the calendar correctly marks tasks as needing recalculation, but nothing afterward actually runs the recalculation or fires the ScheduleEvent that GanttView listens for. So the Gantt chart doesn’t visually update — the stale schedule only gets recomputed the next timethe project is loaded (via initialize()/setBoundsAfterReadProject()), which is exactly the save/close/reopen behavior you’re seeing.
——— The full Claude response —————-
**** Sorry for the formating. I grabbed it with Printfriendly and when I Ctrl-Aed it and pasted, it was very broken up. I tried more than a bit to clean it, but didn’t get all (or maybe even most).****
Project Libre Gantt chart not updating after calendar changes – Claude
claude.ai
/chat/b5e10566-1748-4663-9ccb-f10deb426b17
You said:
I am having problems with Project libre. It is open source software with its code inSourceForge. I would like to find a way to correct what I think is a bug. Can you find the twosource codes in the recent release, version 1.9.8, where 1) the program starts and developsthe initial gantt chart and then 2) where the function is called after a user selects the“Calendar” option in the ribbon, because it is at this point I want to insert the same code fromstartup that develops the Gantt chart, because after I make changes in the calendars, theyare not reflected in the Gantt chart until I save the current version, close Project Libre,andthen reopen it.
Claude said:
Good, this is the right codebase. Now let’s find the calendar ribbon action and the Gantt chartinitialization/refresh logic.
Confirmed — the ribbon button labeled “Calendar” invokes
ChangeWorkingTimeAction, whichcalls doChangeWorkingTimeDialog() in
DocumentFrame.java. Now let’s find how the Ganttchart is built at startup, to compare and find the missing refresh call.
What I found
I cloned the official ProjectLibre source mirror (github.com/smartqubit/projectlibre, samecodebase lineage as the SourceForge 1.9.8 tree) and traced both flows.
1) Where the initial Gantt chart gets built (startup/file‑open) openproj_core/src/com/projity/pm/task/Project.java
initialize()
(~line 325‑329) — called when a project is loaded/created — runs schedulingAlgorithm.initialize(this), a full schedule computation.
1/3
setBoundsAfterReadProject()
(line 2527‑2530) — called right after a file is read —does:
public void setBoundsAfterReadProject() { getSchedulingAlgorithm().setEarliestAndLatest(getStart(), getEnd()); fireScheduleChanged(this, ScheduleEvent.SCHEDULE);}
That fireScheduleChanged(…) call is what notifies GanttView (which implements ScheduleEventListener.scheduleChanged(ScheduleEvent)) to repaint with correct barpositions. There’s also a general-purpose method, recalculate() (line 2772‑2776), already wiredto the existing “Recalculate/Calculate Project” menu action in GraphicManager.java
(~line 1316‑1323):
public void recalculate() { markAllTasksAsNeedingRecalculation(true); schedulingAlgorithm.reset(); schedulingAlgorithm.calculate(true);}
2) Where the “Calendar” ribbon button is handled Confirmed via menu.properties
:
RibbonChangeWorkingTime.text=Calendar
.
Call chain:
GraphicManager.java
(~line 1502) — ChangeWorkingTimeAction.actionPerformed() → DocumentFrame.java
(line 338) — doChangeWorkingTimeDialog() → opens ChangeWorkingTimeDialogBox → ChangeWorkingTimeDialogBox.java onOk()
(line 759) → saveIfNeeded() → saveCalendar()
(line 431‑443) → CalendarService.java saveAndUpdate()
(line 407‑409) → invalidate()
(line411‑424): public void invalidate(WorkingCalendar cal) { Iterator i = cal.getObjectsUsing().iterator(); … hasCal.invalidateCalendar(); // marks tasks dirty … doc.fireUpdateEvent(this, doc); // <– generic object event, NOT a schedule event}
2/3
For Project, invalidateCalendar()
(Project.java line 2116‑2119) does markAllTasksAsNeedingRecalculation(false)
— this marks tasks
stale but never calls schedulingAlgorithm.calculate(true) and never calls fireScheduleChanged(…)
.
The bug, in short
Editing the calendar correctly marks tasks as needing recalculation, but nothing afterward actually runs
the recalculation or fires the ScheduleEvent that GanttView listens for. So theGantt chart doesn’t visually update — the stale schedule only gets recomputed the next timethe project is loaded (via initialize()/setBoundsAfterReadProject()), which is exactly thesave/close/reopen behavior you’re seeing.
Suggested fix location
In
DocumentFrame.doChangeWorkingTimeDialog()
, right after
dlg.doModal();
returns (line357‑358), add:
project.recalculate();
This reuses the exact method already proven to work (it’s what the “Recalculate Project”menu action calls), forcing both the schedule recompute and — if you also add
project.fireScheduleChanged(project, ScheduleEvent.SCHEDULE);
— the Gantt repaintnotification, matching what happens on file load.
Alternatively, the more surgical fix is inside
CalendarService.invalidate()
itself, calling
project.recalculate()
(or at least firing
ScheduleEvent.SCHEDULE
) after invalidating, so
any
calendar-triggering path (not just the ribbon button) benefits.
Let me know if you’d like me to pull the exact surrounding code blocks into a diff/patch youcan apply directly.
3/3