Reordered the English translations. Added French and German translations.

Ayush Anand authored 8 months ago and Albert Gräf committed 6 months ago

improved code readability

Compilation fixes

See merge request !864

MacOS 11 a.k.a. Big Sur is the last version supported on older MacBooks,
so we stick to that for now. (This is already deprecated on GH CI, so we
might have to move to macOS 12 or 13 in the future.)

- Bugfixes (g_numbox.c, pdgui.js, dialog_search.html).

- Various fixes for better vanilla compatibility (please check the
  commit log for details).

- Added new PURR_DATA and PD_FLAVOR symbols to m_pd.h to make it easier
  for 3rd party externals to check which Pd flavor they're working with.

- Updated pd-lua to 0.11.6 (tutorial updates).

- Revised README (updated some outdated information, removed some l2ork
  branding, fixed some typos and formatting glitches).

In the latest msys2/mingw, libssp-0.dll has gone missing, which was
previously needed for libfluidsynth. Also, libsnfile has a new
dependency on libmpg123-0.dll.

Albert Gräf authored 2 years ago and Albert Gräf committed 1 year ago

Gem has been included in the Mac version for quite some time now, so we
remove the "(Windows and Linux only)" text from the corresponding
section descriptions in the help browser.

The problem that we're trying to solve here is that there is no reliable
way for objects to be notified when the edit mode status of their canvas
changes. This problem exists across various flavors, but is made worse
in Purr Data because it uses an ancient version of the canvas_editmode
method which interprets a zero argument to mean "toggle", not "off".

This makes it virtually impossible for 3rd party objects to observe edit
mode changes while they are still in progress, as they simply cannot
know whether the edit mode bit has already been flipped or not.

The solution: Killing two birds with one stone, we first refactor
existing gui notifications about edit mode changes in various places so
that they now all go through a single function canvas_announce_editmode.
This function then goes on to call the new canvas_dispatch_editmode
function which takes care of notifying all receivers on the C side,
after which the gui gets notified as before.

This also makes sure that the new edit mode status is announced in both
temporary run mode (set in the key handler) and calls to
canvas_editmode and canvas_query_editmode (both direct and through the
message interface), which should cover all relevant cases.

NOTE: The receiver symbol is canvas-specific and takes the form
<canvas>#editmode where <canvas> is the canvas id (hex code), so that
presumably only objects on the specific canvas will receive the message.

[declare -legacy] enables legacy positioning as with the global -legacy
flag, but on a canvas-local basis. If not set in a patch, the flag
defaults to its global counterpart. Note that there is no argument, so
you can only enable this, not disable it. Moreover, once set, the flag
is inherited by all subpatches.

This declaration allows you to use vanilla subpatches in Purr Data where
iemguis are positioned in a slightly different way, which may cause gop
patches created in vanilla to be rendered incorrectly.

Adding [declare -legacy] to the vanilla subpatch gets rid of these
issues, while the rest of your patch is rendered as usual. Note that the
global -legacy startup option will affect *all* patches loaded by Purr
Data, which doesn't help if only some subpatches must be rendered in a
vanilla-like fashion.

Previously we only had fwd (from GSoC 2020).

Backport from:
https://github.com/pure-data/pure-data/commit/a5a8a3ba
https://github.com/pure-data/pure-data/commit/377f1947

This is for the benefit of 3rd party external libraries which may need
to know which Pd flavor they're working with. We've had the PDL2ORK
symbol in m_pd.h for a while, but with DISIS Pd-l2ork 2 that's no longer
unambiguous, so we added the PURR_DATA symbol now.

We also added a new PD_FLAVOR symbol which is defined to be a string
describing the Pd flavor. This is currently only present in Purr Data's
m_pd.h header, of course, but it might conceivably be picked up by other
active flavors such as plugdata in the future.

The crash was being triggered by last_thing being null when the append
callback was invoked. I noticed this, e.g., with ELSE's else and message
help patches, which otherwise look pretty innocent.

So it seems that last_thing *can* in fact be null when the append
callback is being invoked in certain situations. Whatever the cause may
be, the canvas gui crashing is definitely *not* an acceptable outcome in
*any* situation. This commit deals with that condition by effectively
turning the operation into a no-op, which seems to be the only thing
that we can possibly do in this case.