Like musrFT and musrt0: set a compiled-in xpm icon (rendered from
mupp-plain.svg) and the class hint "mupp_plot" on the TRootCanvas, and on
Linux install a matching .desktop file and 48x48 icon to MUSRFIT_XDG_DATA_DIR,
refreshing an existing gtk icon cache. Done for the Qt6 and Qt5 plotter.
musrview writes its PNGs next to the msr-file as <msr>_<n>.png, hence the
plain, -f and -f -a tests of the same msr-file overwrote/removed each
other's PNGs when run in parallel. Lock them on the msr-file.
Adds test-LSCO-asy-ZF.msr with its data file lem07_his_0592.root, a
maxLH_check (chisq) test, and musrview_check tests (time domain and
Fourier) including their reference PNGs.
- PFourierCanvas.h only forward declares PFourier. Including PFourier.h put
fftw3.h into the dictionary payload, and cling (ROOT 6.40, macOS SDK 26+)
fails on its '#include <stddef.h>', which lost the interpreter info of
PFourierCanvas and with it all its signal/slot connections.
- musredit: run musrFT in the directory of the msr-file and write musrFT.log
there. Started from the Finder/Dock the working directory is '/', the log
cannot be written and QProcess refused to start musrFT. Merge stderr into
the log, show the full command and the reason if starting fails.
Port of adc991f72 (root6). The ROOT canvas sets the macro_s.xpm icon and
WM_CLASS "ROOT". Set a compiled-in xpm icon and a per-tool class hint, and
install matching .desktop files (with full Exec path) and icons to
MUSRFIT_XDG_DATA_DIR. An existing gtk icon cache is refreshed at install time.
musrview was already handled on this branch.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With the usual install prefix ($ROOTSYS) the .desktop files and icons ended
up in $ROOTSYS/share, which is neither in $XDG_DATA_HOME nor $XDG_DATA_DIRS.
They now go to MUSRFIT_XDG_DATA_DIR, defaulting to the system share dir for
/usr and /usr/local prefixes and to $XDG_DATA_HOME (~/.local/share) otherwise.
The .desktop files are configured from templates so that Exec= holds the full
path of the binary, since $ROOTSYS/bin is typically not on the PATH of the
graphical session.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
musrview is a plain executable, hence on macOS it showed up with the generic
'exec' icon. The QApplication behind the embedded display is created by ROOT,
musrview now sets its name and icon after the first window is shown (needs
Qt6::Widgets, the same Qt ROOT's qt6web links against).
- new application icon src/musrview_web/musrview.svg/.png, installed next to
musrview.html and found the same way (PMusrWebCanvas::WebDir())
- macOS: an Info.plist embedded into the binary gives name and bundle id
- Linux: musrview.desktop plus hicolor icons, and setDesktopFileName() so that
Wayland compositors can match the window to its icon
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"Export data" asked for the file name in a plain prompt, proposing a fixed
musrview_export.dat relative to the current working directory.
It now opens the same ROOT openui5 file dialog (RFileDialog) as "Save
graphics"; the page code of the dialog serves both toolbar entries. It
proposes <msr-base>_<plotNo>[_F].dat in the directory exported to last
(exportname:/EXPORTNAME:, NextExportFileName()), counted up until the name
does not exist yet. Its file type list offers .dat, .txt and any file; typing
an unknown extension selects the latter so that none gets appended. The file
name of 'export:' is now percent encoded as the one of 'save:'. If the dialog
is not available, the prompt is used as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A 'Tooltips' toolbar button (key: h) switches the JSROOT hover box showing
x, y and the errors of a data point on and off. The state is re-applied
after every redraw and persisted in localStorage like the panel visibility.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"Save graphics" used to write a file with a generated name into the current
working directory and hand it to the browser as a download, the format being
chosen in a separate selector of the toolbar.
It now opens ROOT's openui5 file dialog (RFileDialog), embedded as a channel
of the musrview window, in which the location and the name of the file are
chosen. Its file type list (png, pdf, svg, eps, gif, jpg, xpm, root) selects
the graphics format and replaces the toolbar selector; typing a name with
another supported extension selects that type rather than getting the
selected one appended. The dialog starts in the directory saved to last with
a name which does not exist yet, and asks before overwriting a file.
The dialog browses the machine musrview runs on, hence the file is written
there directly (SaveGraphicsAs()) instead of being served as a download, and
the "currentdir/" location of the web window is no longer opened. openui5 is
loaded on the first save only; if it, or libROOTBrowserv7 on the server side,
is not available, a plain prompt asks for the file name instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The interactive export always produced the classic 800x600 layout, so neither
the size of the musrview window nor the proportions the user had dragged the
'Fit parameters', 'Theory' and 'RUN INFO' panels to showed up in the saved
graphics.
The page now measures its current view -- window size without toolbar and
status bar, the height of the title and the run info, the width of the
parameter/theory column, the split between the two, plus the font size of the
panels -- and hands it over with the 'save:' message. A boundary which is a
splitter bar on screen is reported as the bar's centre line, since the export
draws the blocks edge to edge.
The C++ side takes that as the new ExportGeometry, which replaces the hard
wired fractions in RenderGraphics(). With a font size given, the panels keep
the size the text has on screen (with the line spacing of the HTML panels)
rather than TPaveText/TLegend scaling the text up to the pave: a larger window
then shows more text instead of bigger text, as the HTML panels do. The text
is only ever scaled down, as far as the pave needs it in height and in width,
the latter measured the way TPaveText measures it.
ExportGeometry's defaults are exactly the previous layout, hence the
--png/--pdf/... batch export, which has no window to take anything over from,
is unchanged -- bit for bit, the musrview_check reference images included.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Restores the root6 behaviour: saving the same view twice from the
musrview window no longer replaces the file written before. Starting from
the number of the PLOT block, the index of the default name is counted up
until a free one is found, i.e. <msr-base>_0.png, <msr-base>_1.png, ...
(and _0_F.png, _1_F.png, ... in the Fourier representation, which thus
counts on its own, as does every graphics format).
The name construction moves from DefaultGraphicsBaseName() into the new
GraphicsBaseName(plotNumber), so that the batch export and the
interactive save keep sharing one naming rule. The --png/--pdf/... batch
export keeps overwriting: it writes one file per PLOT block and the
reference images of the test suite rely on those names.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LVGQWoKNXByP2PSmMgPz3i
RenderGraphics() flips gROOT's batch flag so that the export TCanvas is
built headless. That is enough for TCanvas to take its batch branch, but
not enough to make the session batch: an interactive musrview is a
non-batch ROOT session, hence TApplication has loaded the X11 graphics
and gVirtualX points at TGX11.
A batch TCanvas never obtains a drawable - its fPixmapID stays -1 - yet
TCanvas::Build() unconditionally paints the canvas background through
SelectDrawable(fPixmapID)/PaintBorder(). With the batch gVirtualX that is
a no-op, with TGX11 it selects window -1 and TGX11::DrawBoxW() segfaults.
Saving from the musrview window therefore crashed every time, while the
--png/--pdf/... batch export was never affected (there gVirtualX already
is the batch one).
Put the graphics interface into the same state a genuine batch session
has by pointing gVirtualX at ROOT's gGXBatch for the duration of the
export. Batch flag and gVirtualX are now handled by one RAII guard, which
also replaces the three hand-written restore points, and which is
declared before the canvas so that it outlives it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LVGQWoKNXByP2PSmMgPz3i
The panel used a fixed 28% of the window height regardless of content,
which left mostly empty space for the common single-run/single-histo case.
Now, for plots with 1-5 run/legend entries, the panel is sized to what its
own content actually needs; 6+ entries keep the previous behavior (the
size the user last dragged to, or the 28%-of-viewport default).
Measuring the true content height needs care: Element.scrollHeight only
reports the *overflowing* content height, so while the content still fits
inside the page's initial placeholder box it just echoes that box's
(unrelated) size back. measureInfoContentHeight() briefly frees the
element from its flex/height constraint to read its real intrinsic size,
and measureInfoPanelHeight() adds the "RUN INFO" header's own height on
top, since the sized grid row covers header and content together.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ports the theory-color highlight toggle from the root6 PMusrCanvas::
HandleCmdKey() to the new web-based musrview: pressing 't' highlights the
theory curve in red/bold for a single-data-set plot, matching root6's
long-standing "toggle theory color" shortcut which was missing after the
ROOT7 rewrite.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
int32 Vgetname(int32 vkey, char *vgname)
to
int32 Vgetname(int32 vkey, char *vgname, size_t *buf_size)
(a fix for a buffer-overflow issue). Detect which one is present so
PNeXus.cpp can call the right form for both old and new HDF4 releases.
Previously the interactive "Save graphics" export always rendered the
title/parameters/theory/run-info blocks regardless of which panels the
user had shown or hidden in the live view. The client now sends the
current panel-visibility state alongside the format, and the server's
export layout collapses a hidden block's space onto its neighbours
(matching the CSS grid logic already used for the live view), instead
of always drawing every block.
Also fixes an unrelated, pre-existing bug in the live view surfaced
while testing this: #panel-params/#side-split/#panel-theory relied on
implicit DOM-order placement into #side's three grid rows, but hiding
a panel uses display:none, which removes it from grid flow rather than
just collapsing it -- so hiding both Parameters and the splitter left
Theory as the grid's only item, auto-placed into the wrong (0px) row.
Pinned each to an explicit grid-row so hiding siblings can't shift it.
Finally, the "Save graphics" toolbar entry gave no feedback at all: the
embedded Qt6 WebEngine auto-accepts downloads with no dialog, so the
status bar now reports "graphics written (<file>)" on success.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012PdYEZbK4eUTVuUxGswVS9
Add drag handles between the plot and the side column, between the Fit
parameters/Theory panels, and above the Run info panel, so their width/height
can be adjusted interactively. Sizes are clamped to the viewport and persisted
in localStorage, reusing the pattern already used for panel visibility.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BjACu9ZD3FGfp1Db32DoiQ
root6 musrview could save the plot as png/pdf/svg/...; the ROOT7 web
rewrite dropped that. Add a "Save graphics" toolbar entry: the server
renders the classic layout (same code path as --png/--pdf/... batch
export) into the current working directory and hands it to the browser
as a download, so the browser's own save dialog/download folder decides
where it lands -- a native OS folder picker isn't reachable from here,
since the --embedded window is a Qt6 QWebEngineView owned by ROOT itself,
which auto-accepts downloads with no dialog.
Also fixes rasterized batch export (png/gif/jpg) coming out blank when
triggered from an already-running interactive session: TCanvas decides
at *construction* time, from gROOT->IsBatch(), whether to build a real
GUI canvas or a headless one, so canvas.SetBatch(kTRUE) after the fact
was too late. Vector formats (pdf/eps/svg) don't need pixel readback and
were unaffected, which is why this went unnoticed. Fixed by toggling
gROOT's batch flag for the export canvas's lifetime.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017cuZPrSNaKjG8xHPVNwV16
check_cxx_source_compiles() caches MUSRVIEW_HAS_ROOT7_API under a plain
variable name with no dependency tracking, so a failure recorded once
(e.g. against an older ROOT built into the same build/ directory) kept
being reported as missing on every later reconfigure even after ROOT was
fine. Unset both cache entries before the check so it always re-runs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Since musrview is built on the ROOT7 web graphics it needs a fair number of
ROOT build options which are not all on by default. Without them musrview
either does not compile at all or, worse, compiles and then shows a blank
window at run time. The only check so far was for the ROOT::ROOTWebDisplay
target.
The new cmake/MusrfitCheckROOT7.cmake collects all problems and reports them
in one go, together with the ROOT cmake flags needed to fix them:
- the ROOT build options root7, webgui and http (ROOT_<option>_FOUND),
- the libraries ROOT::ROOTWebDisplay and ROOT::RHTTP,
- the headers ROOT/RWebWindow.hxx and ROOT/RWebWindowsManager.hxx,
- the API itself, through a compile-only check of the calls musrview and
PMusrWebCanvas make. If that fails it is retried in the ROOT::Experimental
namespace, which tells the user that the ROOT is older than 6.32 instead of
leaving them with a compiler error,
- JSROOT: the js directory (overridable with -DMUSRVIEW_JSROOT_DIR=<dir>), the
modules musrview.html imports and the '<!--jsroot_importmap-->' support of
THttpServer which resolves the 'jsroot/...' specifiers.
Not fatal, but warned about and shown in the config summary:
- MUSRVIEW_HAS_QT6WEB: without ROOT's qt6web musrview falls back from its
embedded window to the standard browser of the system,
- MUSRVIEW_HAS_IMAGE_EXPORT: without libASImage 'musrview --png/--gif/--jpg'
writes nothing. In that case the musrview_check tests, which compare
rendered PNGs, are no longer registered - they could then only fail for a
reason that has nothing to do with musrfit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013Ck7v5F7KjinfC2EyE7K3C
PMusrCanvas was the TCanvas based front end of musrview. Since the ROOT7
rewrite it is no longer part of the build, so drop the class, its header and its
LinkDef rather than leave dead code behind.
Also update the comments in PRunListCollection, PRunMuMinus, PRunSingleHisto
and musrt0 which still named the class, and repair the header comment of
PFourierCanvasLinkDef.h, which carried the file name of the LinkDef it had been
copied from.
Clean rebuild, tests 87/87.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H6YiUNBTMDX9uA3Ts1w2nW
musrview is now a client/server application following the ROOT7 architecture
(S. Linev et al., J. Phys. Conf. Ser. 1525 (2020) 012092): the C++ side holds
the data, an ROOT::RWebWindow ships it as JSON to a JSROOT page which renders
it. This addresses three long standing problems.
The fit parameter, theory and run info blocks were TPaveText/TLegend objects
which scaled their content down until it became unreadable as soon as a fit had
many parameters. They are HTML panels now: fixed font size, own scrollbar, and
each of them can be shown and hidden individually. The run info keeps listing
every run with the very symbol it is plotted with.
The command keys ('d', 'f', 'a', ...) were executed even while a text or latex
label was being typed into the canvas. The page checks whether a text input has
the focus, so typing a 'd' inserts a 'd'.
The plot views were encoded in a set of entangled variables plus a static one
which leaked state between canvases. PMusrViewMode describes them as four
orthogonal properties - domain, Fourier component, difference including whether
it is formed before or after the transform, and average - so that combinations
such as 'Fourier-difference-average' are well defined. PMusrViewModel::GetCurves()
is the single place which maps a view mode onto histograms; plotting and ascii
export both go through it and can no longer disagree, which removed some 700
lines of duplicated view logic from the export.
New classes, namespace musrview:
PMusrViewMode the decoupled view state, free of ROOT and GUI, unit tested
PMusrViewModel the GUI-free data layer, physics taken over unchanged
PMusrWebCanvas the web front end and the graphics export
Further notes:
- The interactive path builds no TCanvas at all, the spectra travel as a TList
of drawables. A TCanvas creates and maps its window already in the
constructor, which would put an empty ROOT canvas next to the musrview window.
- The graphics export keeps the classic pad layout and its 800x600 size and
runs with ROOT in batch mode, so batch operation needs no browser.
- The window opens at 1200x900, since toolbar and panels take their share.
- Non-muSR axis labels are taken from the data file again, and ROOT/TLatex
markup is rendered in the HTML panels as well.
- musrview needs a ROOT built with -Droot7=ON -Dwebgui=ON, plus -Dqt6web=ON for
the embedded window (--embedded, the default). --browser uses the standard
browser of the system, --browser=server only prints the URL.
- PMusrCanvas is no longer part of the build, the files are kept for reference.
Tests: 87/87 pass, among them a new unit test of the view modes and a new
musrview test covering the non-muSR fit type.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H6YiUNBTMDX9uA3Ts1w2nW
Two bug patterns fixed across src/*.cpp:
- musrfit, musrview, any2many, addRun, musrFT, musrt0: a local
success/ok/isGood flag was tracked and an error printed, but the
function fell through to an unconditional `return PMUSR_SUCCESS;`
at the end instead of propagating the failure.
- msr2data, msr2msr: the success path returned a nonzero code (1)
instead of 0.
Also propagate previously-ignored return codes to the process exit
status in dump_header (format-dispatch functions), musrRootValidation
(schema validation / consistency checks), and write_musrRoot_runHeader
(FillFolder failure).
Parameter names in run-specific FITPARAMETER blocks (e.g. alpha_ForwBackw_0139)
kept a trailing '_' after the run-number suffix was stripped for the single-run
and global-mode output. Add StripRunNumberSuffix() and use it at all sites that
remove the suffix, so an immediately preceding separator is removed too.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The gitea-pages workflow runs in the alpine-jupyterbook container,
whose grep lacks PCRE (-P) support, so the version-extraction step
failed. Use a portable awk field scan instead, and fail loudly if
the version can't be found.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extract the project version from the top-level CMakeLists.txt in the
Gitea Actions pages workflow and pass it to Doxygen via the
MUSRFIT_VERSION env var, so musrfit_dox.cfg's PROJECT_NUMBER no
longer needs to be kept in sync by hand.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- src/musrFT.cpp: the timed Transform() loop over all PFourier objects is now parallelized. Added OpenMP::OpenMP_CXX linkage to the musrFT CMake target (it wasn't linked before).
- src/classes/PMusrCanvas.cpp (HandleFourier() and HandleDifferenceFourier()): split each loop into three phases — serial PFourier construction (FFTW plan creation isn't thread-safe), a parallel Transform()
loop (pure FFTW compute, safe to parallelize), and serial ROOT histogram creation/styling (ROOT globals aren't thread-safe). PMusr already links OpenMP, so only the #include <omp.h> and the pragma were
needed.
On gcc-8 (e.g. RHEL8's system compiler, 8.5), std::filesystem is present
but still split out into a separate archive, libstdc++fs.a, so linking
msr2msr failed with undefined references such as
std::filesystem::remove(std::filesystem::__cxx11::path const&, std::error_code&).
gcc>=9 and clang/libc++ ship it in the main runtime library already.
Detect this via an actual compile+link try (first with no extra lib, then
with -lstdc++fs/-lc++fs) instead of guessing from compiler/OS, so
macOS, RHEL9/10, Ubuntu, etc. are unaffected.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Three unrelated issues made the musrview_check tests fail on macOS while
passing on Linux.
1. Unspecified argument evaluation order
TColor::GetColor(rand.Integer(255), rand.Integer(255), rand.Integer(255))
evaluates its (side-effecting) arguments in an unspecified order: clang
goes left-to-right, gcc right-to-left, so the same seed yielded RGB on
one platform and BGR on the other. Visible whenever more runs are
plotted than the startup xml colour list provides, e.g.
test-histo-HAL9500.msr with 16 runs against 10 colours.
The rgb values are now drawn into separate variables first. This keeps
the clang result and changes gcc to match, hence the regenerated
reference PNG for musrview-histo-HAL9500 (99.94% of the differing
pixels were exact R<->B swaps).
Fixed in PMusrCanvas, PFourierCanvas and both mupp PMuppCanvas copies.
2. Fixed size path buffers
char fileName[128] plus strncpy(dst, src, sizeof(dst)) truncates *and*
leaves the buffer unterminated once the path reaches the buffer size.
musrview then failed on a 132 character msr-path in doc/examples/ViewOpts.
musrFT and musrt0 were worse: an unbounded strcpy of the startup file
path into char startup_path_name[128], i.e. a stack buffer overflow.
All path/filename buffers in the drivers are now std::string:
musrview, musrFT, musrt0, musrfit, any2many, addRun, dump_header.
PMusrCanvas::SaveGraphicsAndQuit() takes const Char_t* accordingly.
Along the way in the same files:
- msr2msr_replace() wrote a 256 byte line into char temp[128]
- msr2msr assembled "cp"/"rm" shell commands from paths in a 256 byte
buffer; replaced by std::filesystem
- msr2msr and addRun read lines with getline(buf, N), which silently
abandons the rest of the file on the first over-long line
- addRun: bound the unbounded sscanf "%s" to "%255s"
- dropped scratch buffers that only held a string literal, in favour of
TString::ReplaceAll(const char*, const char*)
3. musrview_check.py left its PNGs behind on failure
The two early error returns skipped the cleanup, and since generated
PNGs were identified by "not in the pre-run snapshot", one leftover file
permanently masked the real output of that test: musrview overwrites the
stale PNG, so it was there, just filtered out. One failure thus poisoned
every later run (30 of the 37 observed failures) after a 15 s poll each.
Cleanup now runs in a finally block on every exit path, and generated
PNGs are detected by mtime instead, which sees rewritten leftovers while
staying safe for a sibling test running concurrently under ctest -j.
Also dropped the MUSRVIEW_PNG_DIR env var and its tmp-dir fallback: it
is read nowhere in src/, so the fallback was dead code that guaranteed
the full 15 s poll before every "no PNGs found" failure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
If Pillow or numpy aren't importable, fail fast with a clear
**ERROR** message and pip-install hint instead of a bare traceback
from inside pixel_diff().
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
HDF4 built with its own CMake build system (rather than autotools) is
commonly installed under a non-standard prefix like /usr/local/hdf4,
which CMake's default find_path/find_library search does not cover,
and names the low-level library 'hdf' instead of 'df'.
Verified working on macOS 27.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
suter_a
