gwyddion-devel Mailing List for Gwyddion

Hello,

Gwyddion 3.5 was released.

This time we broke all data display widgets which were decoupled from
the structre of GWY files and now just display the data you directly
give them. A good progress on g-i annotations was also made. And some
moderate changes in serialisation.

So now we break the GWY file format, switching it to 64bit, and also the
data browser. For some time, the unstable version will not read or write
any [useful] GWY files. The good news is that this should be the last
(or next to last) of ‘everything is broken’ stages.

-----------------------------------------------------------------------------

Libraries:
- libgwyddion: Serialisation API was changed somewhat to have a clearly
  defined intermediate stage (a tree of GwySerialisationGroups), similar
  to libgwyfile representation. Low-level functions work with both 32bit
  and 64bit sizes.
- libgwyddion: Unused resource methods use() and release() were removed.
- libgwyui: GwyDataView now directly takes the data fields, gradients and
  other settings, decoupling it from the structure of GWY files.
- libgwyui: Vector layers directly take selection objects, decoupling them
  from the structure of GWY files.
- libgwyui: Pixmap layers are gone. Set the fields to display directly on a
  GwyDataWiew.
- libgwyui: Separate horizontal and vertical rulers was replaced with just one
  orientable widget.
- libgwyui: Graph basics was removed from public API, except for preset colous
  which were moved to GwyGraphCurveModel.
- libgwyapp: New module utility and other updated functions reflecting the
  changes in data views.
- libgwyapp: Default curve map and volume data previews attemp to filter out
  outliers and a filtering option was also added to the explicit preview
  creation.
- libgwyapp: Curve length was added as a possible curve map preview.

Modules:
- RMI TMD (new): Imports RMI TrueMap Data v2.0 files.
- HDF5: NaNs are masked in generic HDF5 import, fixing a possible crash.
- HDF5: Support for FusionScope .fsexp files was added.
- Curve Map Cut to Segments: Invert option was added for Approach-Retract
  splitting using curves where the split point is at the maximum, not minimum.
- JPK scan: Force curve map import attempts to avoid placeholder pause
  segments, which previously caused a non-uniform channels error. Broken
  segmentation of imported force curve maps was corrected.

Others:
- Dependencies: HDF5 1.12 is now required for HDF5 file format modules.
- Headers: Pragma once was added to headers, speeding up some compilations.

-----------------------------------------------------------------------------

Regards,

Yeti

Gwyddion 2.69 is now available for download at

  https://sourceforge.net/projects/gwyddion/files/gwyddion/2.69/
  (all released files)

  https://gwyddion.net/download/2.69/
  (source code)

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>"
  fingerprint = 7781 7A91 4144 2926 DDE3  E5E5 6D41 82E7 8232 D84B

-----------------------------------------------------------------------------

This is a stable version continuing the 2.x series, backward compatible with
previous 2.x versions.

More information about Gwyddion is available at

  https://gwyddion.net/

Bugs should be reported to

  kla...@gw...

the mailing list, or the project's web forum at SourceForge.

-----------------------------------------------------------------------------

Summary of changes:
Application:
- Translations updated: Czech, Russian.
- File menu: Image stack import was added.

Libraries:
- libgwyapp: Workaround for data browser drag'n'drop dropping wrong data in KDE
  Plasma in Wayland was improved to catch non-image data types.
- libgwyapp: Default curve map and volume data previews attemp to filter out
  outliers and a filtering option was also added to the explicit preview
  creation.
- libgwyapp: Curve length was added as a possible curve map preview.
- libgwyapp: New high-level function for loading an image stack.

Modules:
- Talos (new): Imports ThemoFisher Talos TEM images.
- RMI TMD (new): Imports RMI TrueMap Data v2.0 files.
- Curve map ASCII export (new): Simple export of curve maps to text with one
  curve per line.
- Curve map ASCII import (new): Read back the curve map text export format.
- Curve Map Cut to Segments: Invert option was added for Approach-Retract
  splitting using curves where the split point is at the maximum, not minimum.
- Igor: Mismatched channel titles in exported IBW files were corrected.
- HDF5: Invalid/missing values in DATX are handled correctly now (by masking
  and interpolating).
- Nanoscope: Files with explicit Slow Axis Size do not have the vertical size
  corrected twice any more, which resulted in wrong physical dimensions.
- DME file: Possible crash in MS Windows upon file import was fixed.
- JPK scan: Force curve map import attempts to avoid placeholder pause
  segments, which previously caused a non-uniform channels error.
- MFM Current Line and Parallel Field: Memory handling bugs were fixed.

-----------------------------------------------------------------------------

Thanks all who contributes,

Yeti

Hello,

we would like to release version 2.69 in a couple of weeks. Most of the
changes are bug fixes which do not require any translation updates but
there are a few new modules and functions.

Regards,

Yeti

Hello,

Gwyddion 3.4 was released.

Gobject-introspection was added, so you can use Gwyddion 3 libraries in
Python – in principle. Adding the support is one thing; adding zillion
annotations to the C code to make g-i useful is another.

Otherwise it was mostly about getting things to a somewhat better shape
in order to break them again – which is coming. If there are to be
changes in the file structure (there will be), they need to be done
early. However, there are other changes that will make it less painful.
Overall, it is progressing…

-----------------------------------------------------------------------------

Libraries:
- Headers: A simple include-everything gwy.h header was added.
- libgwyddion: Most members of data objects were moved to private structs.
  Basic properties such as pixel or physical sizes still remain public (for
  reading).
- libgwyddion: Unit setter functions, which were an eternal source of bugs,
  were finally removed. Use a getter and modify the unit.
- libgwyddion: Data compatibility checking functions and types were renamed
  to indicate clearly they are in fact checking incompatibility.
- libgwyddion: GwyContainer can be marked as in-construction for the initial
  construction, in particular in file import modules.
- libgwyapp: New GwyFile subclass of GwyContainer to represent specifically
  GWY files (currently unused).
- libgwyapp: Workaround for data browser drag'n'drop dropping wrong data in KDE
  Plasma in Wayland was improved to catch non-image data types.
- libgwyapp: Header files are actually installed to libgwyapp directory, not
  still the old app directory.
- libgwyapp: Items in metadata browser can be filtered by name.

Modules:
- Talos (new): Imports ThemoFisher Talos TEM images.
- Curve map ASCII export (new): Simple export of curve maps to text with one
  curve per line.
- Curve map ASCII import (new): Read back the curve map text export format.
- PS-PPT: Metadata reading was restored.
- Igor: Mismatched channel titles in exported IBW files were corrected.
- HDF5: Invalid/missing values in DATX are handled correctly now (by masking
  and interpolating).
- Nanoscope: Files with explicit Slow Axis Size do not have the vertical size
  corrected twice any more, which resulted in wrong physical dimensions.
- DME file: Possible crash in MS Windows upon file import was fixed.

Others:
- Introspection: Initial gobject-introspection support was added, allowing to
  import Gwyddion libraries to Python and other supported languages.
- Dependencies: We switched from JANSSON to JSON-GLib which is already used by
  GTK+ due to namespace conflicts between the two libraries.
- Source packages: Each library has its own .pc file now. Replace requiring
  gwyddion with libgwyapp. Simple programs may only require libgwyddion.
- Tests: Were moved to the top-level directory.

-----------------------------------------------------------------------------

Regards,

Yeti

On Tue, Jun 17, 2025 at 10:17:18PM +0000, Rui wrote:
> This is Rui, a homebrew maintainer, recently I am seeing some regression build
> failure with gwyddion 2.68 against autoconf ≥2.72. 

I am building Gwyddion (including autogen) with autoconf 2.72 just fine
in Fedora 42.

Is this really an autoconf 2.72 issue?

What is the failure you observe?

> +AM_GNU_GETTEXT_VERSION([0.19])

This is weird, although adding it probably would not do any harm.

As far as I can tell the macro has always been defined as noop

    dnl Usage: AM_GNU_GETTEXT_VERSION([gettext-version])
    AC_DEFUN([AM_GNU_GETTEXT_VERSION], [])

and exists for autopoint to read the version information.

Gettext documentation explicitly says to use AM_GNU_GETTEXT_VERSION()
(or the other _VERSION macro) if one uses autopoint. We do not use
autopoint.

Autopoint seems the only consumer of AM_GNU_GETTEXT_VERSION (it is also
touched by gettextize, but gettextize only tries to update the version
if the macro is present; it does not do anything else with it).

Does something in your build system try to run autopoint
indiscriminately?

Yeti

Hi,

This is Rui, a homebrew maintainer, recently I am seeing some regression
build failure with gwyddion 2.68 against autoconf ≥2.72.

Below is the my patch to fix the build on the homebrew side (
https://github.com/Homebrew/homebrew-core/pull/227187)

diff --git a/configure.ac b/configure.ac
index b1f75d4..8a0895c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -883,6 +883,7 @@ AC_CHECK_FUNCS([sincos log2 exp2 lgamma tgamma j0 j1 y0
y1 log1p expm1 memrchr m
#############################################################################
# I18n
GETTEXT_PACKAGE=$PACKAGE_TARNAME
+AM_GNU_GETTEXT_VERSION([0.19])
AM_GNU_GETTEXT([external])
AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE,"$GETTEXT_PACKAGE",[Gettext package
name])
AC_SUBST(GETTEXT_PACKAGE)


Let me know if that makes sense.

Thanks,
Rui

Hello,

Gwyddion 3.3 was released.

This was a fairly disruptive version, with lots of moving and renaming
of source code files. And it will get worse before it gets better. But
it is going reasonably well.

-----------------------------------------------------------------------------

Application:
- Remote control: The program was rebased on GApplication which serves as the
  universal backend for opening files in a running Gwyddion. Platform-specific
  backends were removed. There are still a number of rough edges and subtle
  behaviour changes.

Libraries:
- libgwydraw: Gone. Basic data structures and classes (GwyRGBA or GwyGradient)
  were moved to libgwyddion. Utility drawing functions were moved to
  libgwydgets.
- libgwymodule: Gone. Functions were moved to libgwyapp.
- libprocess: Gone. Functions were merged to libgwyddion.
- libgwydgets: Renamed to libgwyui.
- libgwyapp: Directory was finally renamed from app to libgwyapp.
- libgwyddion, libgwydgets: Selections were moved to libgwyddion.
- libgwyddion: GwyGradient and GwyGLMaterial are now serialisable.
- libgwyddion: gwy_find_self_dir() was replaced with more universal
  gwy_find_self_path()
- libgwyddion: Mostly switched to standard means of giving context to
  translatable messages, removing our own macros but keeping gwy_sgettext()
  with some changes.
- libgwyddion: gwy_data_field_invert() X and Y flipping arguments were
  swapped to the logical order (matching other data objects).
- libgwyddion: Various obsolete functions were removed, such as the oldest
  set of 2D polynomial fitting functions.
- libgwyddion: Most functions with non-standard masking and area arguments,
  e.g. without masking type, were modified to have standard mask, masking and
  area arguments.
- libgwyui, libgwyapp: GtkGLExt-style OpenGL initialisation and checking
  functions were removed. Other initialisation functions were also merged
  and/or cleaned up.

Modules:
- Volume clustering (new): Volume data clustering, replacing volume k-means
  and k-medians and adding new methods, such as DBSCAN.
- K-means, K-medians: Removed (replaced with Volume clustering).

Others:
- Icons: SVG icons are used directly instead of rendering them to PNGs.
  Inkscape and pngcrush are no longer used when building from svn.
- Build: Auxiliary build files were moved to build-aux, cleaning up the top
  level directory somewhat.

-----------------------------------------------------------------------------

Regards,

Yeti

Hello,

if anyone is following the GWYDDION-UNSTABLE branch, I've just switched
Gwyddion icons to directly use SVG (instead of prerendering everything
to PNG with Inkscape during a fresh build).

It went relatively smoothly, except it made a huge mess in pixmaps. A
bunch of previously ignored files and directories have become versioned,
leading to some ugly tree conflicts in a typical working copy. Doing
‘make maintainer-clean’ in pixmaps frist should allow a clean svn
update. A fresh checkout is probably the easiest option though.

Regards,

Yeti

Hello,

Gwyddion 3.2 was released.

The GTK+ cleanup continues. But the main part is rewritten serialisation,
with better error handling and hopefully no longer eating all memory in
the universe on file saving. Mainly, however, individual objects no longer
deal with serialised bits an bytes, just specify what data they have. So
things like representing Gwyddion data 1:1 in HDF should be reasonably
possible.

-----------------------------------------------------------------------------

Summary of changes:
Libraries:
- libgwyddion: A simple error list data type was added.
- libgwyddion: Serialisation was rewritten. It is now format-agnotsic
  (declarative) with better error handling and other improvements.
- libgwyddion: Serializable boxed types were introduced, implemented by
  GwyXY, GwyXYZ and GwyRGBA.
- libgwyddion, libprocess, libgwydgets: Unified standard serialisable
  functions to copy() and assign().
- libgwyddion: Cleanup of GwyContainer string functions arguments regarding
  constness and signedness.
- libgwyddion: Moderate cleanup of GwyResource, with some explicit support for
  unmanaged resources.
- libprocess: Copying functions which used to inconsistently copy various bits
  were unified to copy_data() which always copies just the data.
- libgwyprocess: Fixed brick transposition not updating the real dimensions
  correctly.
- libgwydgets: GwyGradientSwatch can display markers and act as a slider.
- libgwydgets: Colour wheel HSV colour editing widget was added.
- libgwydgets: Color editor and color editor dialog widgets were added.
- libgwydgets: Vector layer method signatures were modified to be more useful
  and less follow GTK+ event controllers.

Modules:
- Zyvex (new): Imports ZyVector Scanz data files.
- Accurion ellipsometry (new): Imports ASCII data maps exported from Accurion
  ellipsometers.

Others:
- Libraries: Libraries are no longer called libgwysomething2, but with 3.
- Tests: A test suite has started, currently covering parts of libgwyddion.

-----------------------------------------------------------------------------

Regards,

Yeti

Gwyddion 2.68 was released, sort of. We seem to be affected by a
SourceForge bug. So we hope Gwyddion 2.68 will soon be also available
for download at

  https://sourceforge.net/projects/gwyddion/files/gwyddion/2.68/
  (all released files)

but at present only the following works

  http://gwyddion.net/download/2.68/
  (source code)

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>"
  fingerprint = 7781 7A91 4144 2926 DDE3  E5E5 6D41 82E7 8232 D84B

-----------------------------------------------------------------------------

This is a stable version continuing the 2.x series, backward compatible with
previous 2.x versions.

More information about Gwyddion is available at

  http://gwyddion.net/

Bugs should be reported to

  kla...@gw...

the mailing list, or the project's web forum at SourceForge.

-----------------------------------------------------------------------------

Summary of changes:
Application:
- Translations updated: Czech.

Libraries:
- libgwyprocess: Functions for angularly averaged 2D PSDF were added.
- libgwyprocess: Fixed brick transposition not updating the real dimensions
  correctly.
- libgwyapp: Row levelling in file open preview was changed to median, avoiding
  the global tilt sometimes added by median difference.
- libgwyapp: GwyParamTable reset is actually handled for range-from and range-to
  type controls.
- libgwyapp: Items in metadata browser can be filtered by name.

Modules:
- Volume clustering (new): Volume data clustering, replacing volume k-means
  and k-medians and adding new methods, such as DBSCAN.
- Zyvex (new): Imports ZyVector Scanz data files.
- Accurion ellipsometry (new): Imports ASCII data maps exported from Accurion
  ellipsometers.
- K-means, K-medians: Removed (replaced with Volume clustering).
- HDF5 and a dozen other file modules: Import is now corectly recorded in the
  log.
- 2D ACF, 2D PSDF: Wrong sensitivity of target graph selector was fixed.
- 2D PSDF: The output curves are just sections of the 2D PSDF and have the same
  units as 2D PSDF.
- Statistical functions: Angularly averaged PSDF was added.
- Wave synthesis: Incorrect phase and amplitude outputs for cosh waves were
  corrected. Complementary displacement wave output was added. Underflow is
  handled better, allowing farther sources with decay.
- Coerce: Skew parameter of skew-normal distribution can be negative.
- Curve Map Find Position: Fixed possible crash when working with individual
  curve segments.
- Frequency split: Spectral density plot not displaying with wide and flat
  images was corrected.

Others:
- Compilation: Python detection on python3-only systems was fixed, making
  build scripts actually work there.

-----------------------------------------------------------------------------

Thanks all who contributed,

Yeti

Hello,

Gwyddion 3.1 was released.

A summary of major changes follows, although the main feature of this
version is ‘compilation now gives about 5000 fewer warnings’. With this
out of the way the following 3.x versions should be a bit more focused,
although porting and cleanup are still far from being done and will
continue for some time.

I think I forgot to send e-mail about 3.0. Sorry about that. Its main
feature was probably ‘cataclysm’.

-----------------------------------------------------------------------------

Summary of changes:
Libraries:
- libgwyddion: Useless parameters and deprecated functions were removed from
  NL fitter and fit functions.
- libgwyprocess: Functions with subnames starting with a number, like
  gwy_data_field_2dfft(), causing problems in language bindings, were renamed.
- libgwyprocess: Useless interpolation arguments were removed from various
  FFT, ACF and HHCF functions.
- libgwyprocess: Deprecated tip modelling types and functions were replaced
  with a new GwyTipModel resource class.
- libgwyprocess: Useless parameters and deprecated functions were removed from
  Critical Dimension.
- libgwydgets: All Gwy3DSomething types were renamed to GwyGLSomething
  (including header file names) to avoid names starting with numbers in
  language bindings.
- libgwydgets: GwyAxis was renamed to GwyGraphAxis.
- libgwydgets: Auxiliary graph dialogs were restored.
- libgwydgets: New GwyFitTable and GwyCorrelTable helper widgets for fitting
  parameters and correlation matrices.
- libgwydgets: New gradient and colour swatch widgets and cell renderers were
  added.
- libgwydgets: GwyCurve and GwyMarkerBox are gone for good.
- libgwyapp: GwyParamTable now supports compact single-line checkbox rows.
- libgwyapp: Colour gradients are editable again (using a simple editor
  different from 2.x).
- libgwyapp: Graph thumbnails work again.

Modules:
- Tip blind estimate, Grain filter, Volume FD fit, Immerse, Convolution filter,
  XYZ average, XYZ merge: Restored.
- Graph image exports: Reimplemented as a new module exporting to pixel images,
  SVG, PDF and PostScript.
- Stitch: Options to perserve global offsets and create a mask over missing
  data were added.
- Immerse: An option to draw the detail with main image colour range was added.
- Graph, volume and curve map fitting: GUI was unified with Fit Shape using the
  new helper widgets. Graph FD fit was merged into the graph curve fit module.
- Volume FD fit: GUI was unified with Fit Shape using the new helper widgets.
  Outputs can be controlled with checkboxes; correlation matrix outputs have
  not been implemented yet.
- XYZ modules: Non-disabled modules build correctly (XYZ modules were missing
  completely in 3.0).
- PS-PPT: Metadata were disabled (temporarily) because namespace conflics
  between JSON libraries cause crashes.
- Pixmap: Is now bundled if module bundling is enabled.
- HDF5 and a dozen other file modules: Import is now corectly recorded in the
  log.
- 2D ACF, 2D PSDF: Wrong sensitivity of target graph selector was fixed.
- 2D PSDF: The output curves are just sections of the 2D PSDF and have the same
  units as 2D PSDF.
- Statistical functions: Angularly averaged PSDF was added.
- Wave synthesis: Incorrect phase and amplitude outputs for cosh waves were
  corrected. Complementary displacement wave output was added. Underflow is
  handled better, allowing farther sources with decay.
- Coerce: Skew parameter of skew-normal distribution can be negative.
- Curve Map Find Position: Fixed possible crash when working with individual
  curve segments.

Others:
- Compilation: zlib and libpng are now required, not just optional.

-----------------------------------------------------------------------------

Yeti

Hello,

we would like to release version 2.68 in about two weeks. Petr is
finishing the new volume clustering module, and that should be the last
substantial change.

Regards,

Yeti

On Thu, Jan 30, 2025 at 06:02:37PM -0600, Moutaz Haq wrote:
> I would like to submit a new file module for loading ZyVector Scanz
> (.zad) files.
> ZyVector Scanz (.zad) files are created by the Scanz software as part of the
> ZyVector STM controller from Zyvex Labs.

Nice, we are always looking for more file formats to support.

> Please let me know how to contribute the source file. I can also provide sample
> .zad files for testing.

File modules are pretty self-contained, usually just a single source file.
So the initial process is to just send it to me (including sample files
please).

Regards,

Yeti

I would like to submit a new file module for loading ZyVector Scanz
(.zad) files.
ZyVector Scanz (.zad) files are created by the Scanz software as part of the
ZyVector STM controller from Zyvex Labs.

Please let me know how to contribute the source file. I can also provide sample
.zad files for testing.

-- 
Moutaz Haq
Zyvex Labs LLC

On Fri, Dec 06, 2024 at 12:31:18PM -0600, Moutaz Haq wrote:
> I'm trying to install the mingw packages from the gwyddion-mingw repo
> but it appears the repo is down. dnf reports a 404 error on trying to
> access http://gwyddion.net/download/fedora-mingw/40/x86_64/os/repodata/repomd.xml

There is no F40 mingw repo because it would not do any good. I had to
mantain backports even in earlier versions. At some point that stopped
working too, probably due to changes in more low-level mingw packages.
I simply do not know how to cross-compile working Gwydidon in recent
Fedora. We use F34 and the repo for it is up – you can use too, e.g. in
a virtual environment… I am sorry for the inconvenience.

Yeti

I'm trying to install the mingw packages from the gwyddion-mingw repo
but it appears the repo is down. dnf reports a 404 error on trying to
access http://gwyddion.net/download/fedora-mingw/40/x86_64/os/repodata/repomd.xml
.

Thanks,
Moutaz

Gwyddion 2.67 is now available for download at

  https://sourceforge.net/projects/gwyddion/files/gwyddion/2.67/
  (all released files)

  http://gwyddion.net/download/2.67/
  (source code)

Released files are signed with PGP/GnuPG key

  "David Nečas (Yeti) <ye...@gw...>"
  fingerprint = 7781 7A91 4144 2926 DDE3  E5E5 6D41 82E7 8232 D84B

Note that the key has changed and for this release the files are signed
by both the old and new keys (separately).

-----------------------------------------------------------------------------

This is a stable version continuing the 2.x series, backward compatible with
previous 2.x versions.

More information about Gwyddion is available at

  http://gwyddion.net/

Bugs should be reported to

  kla...@gw...

the mailing list, or the project's web forum at SourceForge.

-----------------------------------------------------------------------------

Summary of changes:
Application:
- Translations updated: Czech, Russian.

Libraries:
- libgwyddion: ACF and PSDF fitting preset initial guesses were improved.
- libgwyddion: Function for checking for a regular lattice was added, able to
  handle rotation and some moderate defects.
- libgwyddion: gwy_raw_data_size() was updated for the new types added since
  2.65 and gwy_raw_data_size_bits() was added, useful for fractional sizes.
- libgwyddion: gwy_convert_raw_data() can handle 10byte x86 ‘extended’ floating
  point numbers.
- libgwyddion: Functions for filling an array with arithmetic progression and
  accumulation/rewind of array of counts were added.
- libgwyprocess: Function for the entire facet levelling procedure was added.
- libgwyprocess: Function for facet distribution computation was added.
- libgwyprocess: Function for polynomial scan line levelling was added.
- libgwyapp: Workaround was added for data browser drag'n'drop dropping wrong
  data in KDE Plasma in Wayland (and possibly other environments).
- libgwyapp: Log message handling can be modified using a new function.

Modules:
- Curve map fit (new): Fits general functions to curve map curves.
- Curve map volumize (new): Converts regular curve map data to volume data.
- XYZ Reduce (new): Reduces number of points in a XYZ data array. 
- XYZ 1D FFT filter (new): Performs FFT filtering in the XYZ data array,
  treating it as time series of equidistant values.
- PFM (new): Performs processing of vector Piezoresponse Force Microscopy
  data consisting of measurements in two perpendicular directions.
- Periodic translate (new): Translate image in the XY plane, treating it as
  periodic.
- Residue synthesis (new): Simulates surfaces resembling film residue after
  partial dissolution.
- HDF5: Support for Nanosurf NHF file format was added. Missing data units
  in EPFL files were corrected.
- Keyence: Wrong physical data scales and metadata in imported VK3 files were
  corrected.
- Nanoscope: Uses FV Lines for the number of scan lines in force volume data.
- Image export: Fonts with attributes like ‘Bold’ or ‘Italics’ are correctly
  loaded back from settings (instead of the font being reset to default).
  Round interpolation should make images in exported SVGs pixelated and masks
  should always be pixelated in SVG (as they are in PDF).
- Correlation length tool: Rewritten using the new self-consistent ACF paper.
  It also displays ACF and PSDF plots and lots of other improvements.
- Volume equiplane, Z-pos level: Crash for data with Z-calibration was fixed.
- Volume Crop: Missing coordinate units were corrected.
- Mutual Crop: Has a preview, can create new images and allows method
  selection.
- Statistical functions tool: Radial ACF subtracts the mean value
  automatically. Result not being always updated upon masking mode changes was
  fixed.
- Volume slice: Clear selection button was added. Fixed previews not
  correctly updating according to changing selection in some cases.
- Volume plane level: Zero mean value function was added.
- Lattice synthesis: Incorrect lattice scaling was fixed.
- Volume facet level: The progress bar actually works and the computation
  is cancellable.
- Fit terraces (image and graph) and volume and graph ASCII export: Output
  files are written with native EOLs, not always Unix.
- Facet analysis: Manual rotation of points works correctly again.
- Frequency split: A PSDF and filter shape plot was added.
- Grain filter: It now actually reads the ranges file with remembered ranges
  the for various quantities when run non-interactively.

Others:
- Compilation: configure now aborts when basic C99 maths functions like cbrt(),
  hypot() or erf() are not available. Gwyddion code has been using erf()
  unconditionally for many years so the change just makes it manifest.
- Compilation: Various auxiliary Python build scripts, generally used in builds
  from subversion, work with any Python version (2.7 or 3.x). Python checks
  were split into pygwy and interpreter for the scripts. Pygwy compiler and
  linker variables are now prefixed PYTHON2_ instead of PYTHON_.
- Plug-in proxy: Configuring with --disable-plugin-proxy now also prevents the
  installation of all plug-in support files.
- Python: Standalone Python module gwy initialises GTK+ more carefully, making
  it work at least to some degree without a display.

-----------------------------------------------------------------------------

Thanks all who contributed,

Yeti

On Tue, Oct 01, 2024 at 04:40:38PM +0200, David Nečas (Yeti) wrote:
> I would like to release 2.67 in the second half of October.

October is obviously not going to happen, but we are getting there. Petr
has finally stopped changing the PFM module (at least for now) and I
promise to stop trying to improve various odd English strings (sorry,
Daniil).

To leave some time for final translation updates, I intend to release
2.67 next Monday (if everything goes well).

Regards,

Yeti

On Tue, Oct 29, 2024 at 02:03:27PM +0000, Shaashwat Saraff via Gwyddion-devel wrote:
> I was trying to install Gwyddion on Arch Linux using the AUR package provided.
> I noted that the latest version (gwyddion-2.66-1, 2024) still depends on Python
> 2, which it was trying to pull into my system. Python 2 has long been
> deprecated and is not recommended for use. Are there any plans to migrate
> Gwyddion to Python 3 on the horizon? 

On the horizon, yes. It involves rewriting everything. Python is then
actually a relatively minor part because most of the work is rewriting
to newer GTK+ and most of the Python part is in fact language-agnostic
introspection support.

The upcoming version 2.67 will build with Python 3. Meaning all
auxiliary build scripts will run happily with Python 3. Of course, there
is no such thing as Python 3 pygwy.

> Perhaps the current version today is indeed independent of Python 2
> but somehow the AUR package dependency specifications were not updated
> and it is wrongly trying to install it? 

No; although almost all the auxiliary Python scripts are for
development, a couple are run during normal builds. And they still need
Python 2 in Gwyddion 2.66.

Another thing is that there will still be lots of *optional* Python 2
stuff. And distros can be weird about optional. So they may make Python
2 a hard dependency or start shouting ’Deprecated! Deprecated! Remove!
Remove!’ or anything between.

> I request you to kindly look into this matter, and would be very happy to help
> in any way I can. 

You can test current development snapshots in a system with no Python 2.

Regards,

Yeti

Dear Gwyddion Developers,

I was trying to install Gwyddion on Arch Linux using the AUR package provided. I noted that the latest version (gwyddion-2.66-1, 2024) still depends on Python 2, which it was trying to pull into my system. Python 2 has long been deprecated and is not recommended for use. Are there any plans to migrate Gwyddion to Python 3 on the horizon?

The last time I had tried to install Gwyddion was in 2021/2022, at which point a (relatively) shorter period had passed since the deprecation of Python 2. I was under the impression then that a later version would be completely independent of Python 2, based on some chatter on online forums. Perhaps the current version today is indeed independent of Python 2 but somehow the AUR package dependency specifications were not updated and it is wrongly trying to install it?

I request you to kindly look into this matter, and would be very happy to help in any way I can.

Thanks and regards,
Shaashwat

On Fri, Oct 11, 2024 at 11:05:14AM -0400, Nicola Ferralis wrote:
> Thanks. To add to the pain, Debian is deprecating support for gtkglext in
> GTK3 as well, since it's unmaintained just the same.

That should actually be fine because there is a GtkGLArea directly in
GTK+ 3 and it should be suitable for what we need. So we will have to
rewrite the 3D view somewhat, but then it will not depend on any
external library.

Regards,

Yeti

Thanks. To add to the pain, Debian is deprecating support for gtkglext 
in GTK3 as well, since it's unmaintained just the same.

Sad indeed.


On 10/8/24 5:11 AM, David Nečas (Yeti) wrote:
> On Tue, Oct 08, 2024 at 12:28:59AM -0400, Nicola Ferralis wrote:
>> It would sure works for now, but become a
>> nightmare when GTK2 is removed from future versions...
> Debian used to offer a vast collection of odd software. Now I can still
> install GTK+ 1.2 to current Fedora by simply doing ‘dnf install gtk+’,
> whereas Debian is going to remove GTK+ 2. Sad.
>
>> I wonder if calling directly on X11 and GL calls would imply in terms of the
>> codebase, and how stable these calls are going forward...
> They are actually pretty stable. But moving them to Gwyddion makes
> little sense. It would certainly create bugs. It would be no less
> unmaintained than gtkglext itself because we have at most a very
> superficial understanding of the gktglext code. We also use gtkglext on
> other platforms, so there would have to be two versions of everything.
> Building entire gtkglext as a part of the Gwyddion build is the only
> sane option.
>
> Anyway, going forward, at some point there will be a GTK+ 3 version of
> Gwyddion (I am working on it). It will be of course incompatible. It
> will also be a very buggy mess for quite some time. And it will not
> magically bring back 3D view. It also needs to be ported, is easy to
> disable and is not a high priority for me.
>
> I hate the idea of having to rewrite programs every five years just to
> keep up with the bloody deprecation cycle. In fact GTK+ 3 itself will be
> EOLed soon (despite very few programs using GTK+ 4).
>
> Regards,
>
> Yeti
>
>

On Tue, Oct 08, 2024 at 12:28:59AM -0400, Nicola Ferralis wrote:
> It would sure works for now, but become a
> nightmare when GTK2 is removed from future versions...

Debian used to offer a vast collection of odd software. Now I can still
install GTK+ 1.2 to current Fedora by simply doing ‘dnf install gtk+’,
whereas Debian is going to remove GTK+ 2. Sad.

> I wonder if calling directly on X11 and GL calls would imply in terms of the
> codebase, and how stable these calls are going forward...

They are actually pretty stable. But moving them to Gwyddion makes
little sense. It would certainly create bugs. It would be no less
unmaintained than gtkglext itself because we have at most a very
superficial understanding of the gktglext code. We also use gtkglext on
other platforms, so there would have to be two versions of everything.
Building entire gtkglext as a part of the Gwyddion build is the only
sane option.

Anyway, going forward, at some point there will be a GTK+ 3 version of
Gwyddion (I am working on it). It will be of course incompatible. It
will also be a very buggy mess for quite some time. And it will not
magically bring back 3D view. It also needs to be ported, is easy to
disable and is not a high priority for me. 

I hate the idea of having to rewrite programs every five years just to
keep up with the bloody deprecation cycle. In fact GTK+ 3 itself will be
EOLed soon (despite very few programs using GTK+ 4).

Regards,

Yeti

In principle it could be included, but there is a strong push against 
including unmaintained software. It would sure works for now, but become 
a nightmare when GTK2 is removed from future versions...

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054392

I wonder if calling directly on X11 and GL calls would imply in terms of 
the codebase, and how stable these calls are going forward...

Thanks,
Nicola



On 10/5/24 1:26 PM, David Nečas (Yeti) wrote:
> On Fri, Oct 04, 2024 at 06:00:16PM -0400, Nicola Ferralis wrote:
>> Recently, debian has decided to drop support for gtkglext (which was
>> unmaintained in debian for years), which can be used in Gwyddion for 3D View:
>>
>> …
>>
>> Is there any other backend that can be used to enable openGL in Debian?
> I doubt there is an alternative GTK+2 OpenGL wrapper. And even if there
> was, it would have suffered the same fate.
>
> In principle you can do everything GtkGLExt does also directly using X11
> and GL calls. But wait, making all those odd calls is exactly what
> GktGLExt is for.
>
> So the ‘best case’ would be including the entire unmaintained GtkGLExt
> codebase directly in Gwyddion. Which would be a clear win for everyone…
>
> Yeti
>
>

On Fri, Oct 04, 2024 at 06:00:16PM -0400, Nicola Ferralis wrote:
> Recently, debian has decided to drop support for gtkglext (which was
> unmaintained in debian for years), which can be used in Gwyddion for 3D View:
> 
> …
> 
> Is there any other backend that can be used to enable openGL in Debian?

I doubt there is an alternative GTK+2 OpenGL wrapper. And even if there
was, it would have suffered the same fate.

In principle you can do everything GtkGLExt does also directly using X11
and GL calls. But wait, making all those odd calls is exactly what
GktGLExt is for.

So the ‘best case’ would be including the entire unmaintained GtkGLExt
codebase directly in Gwyddion. Which would be a clear win for everyone…

Yeti