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.
"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>
"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>
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
Since the Red/Green mode handling was added for NeXus HDF5 IDF V2, the
histogram numbers of the routed histograms carry the period offset, i.e.
histoNo = period*10000 + histo. PRunBase::DeadTimeCorrection() was still
addressing the dead time parameter vector with 'histoNo-1', hence for any
period > 0 it read far beyond the end of the vector. The garbage picked up
there scaled the counts, so every invocation of musrfit gave a different
(sometimes nan) result for the affected run blocks.
The dead time parameters are stored contiguously, period-by-period, and
therefore need to be addressed as period*noOfHistosPerPeriod + histo - 1.
Introduce PERIOD_HISTO_OFFSET for the period encoding, keep the number of
histos per period in PRawRunData, and add PRawRunData::GetDeadTimeParam(histoNo)
which does the mapping and guards against out-of-range access.
Cross-checked against the HDF4 IDF V1 twin of the same run, where the two
periods are flattened into histos 1-192: both readers now yield bit-identical
chisq, with and without dead time correction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
obtained from the data files. Currently the following meta information can be accessed
if available:
field in (G): B or b
energy in (keV): En or en
temperature in (K): since some data files contain a vector of temperature, they have
to be accessed with an index, like T0 or t0, etc.
suter_a
