purr-data merge requestshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests2020-11-02T19:11:03Zhttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/595Improved print dialog2020-11-02T19:11:03ZAlbert GräfImproved print dialogBy popular demand. ;-) Here's the interactive print dialog, as discussed on the mailing list. Also includes some fixes to sys_domicrosleep() backported from vanilla, and the required workaround to prevent crashes upon SIGHUP from the wat...By popular demand. ;-) Here's the interactive print dialog, as discussed on the mailing list. Also includes some fixes to sys_domicrosleep() backported from vanilla, and the required workaround to prevent crashes upon SIGHUP from the watchdog on Linux.2.15.3Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/589Overhaul of fluid~ to add SMMF support and soundfont search, fixes #692.2020-10-12T21:10:16ZAlbert GräfOverhaul of fluid~ to add SMMF support and soundfont search, fixes #692.This is an extensive (but fully backwards-compatible) upgrade of the fluid~ external. It features:
- Support for the [SMMF MIDI message format](https://bitbucket.org/agraef/pd-smmf), which is described in more detail below.
- Canvas di...This is an extensive (but fully backwards-compatible) upgrade of the fluid~ external. It features:
- Support for the [SMMF MIDI message format](https://bitbucket.org/agraef/pd-smmf), which is described in more detail below.
- Canvas directory and path search for soundfont files, so that these can be found more easily without having to use absolute pathnames. The .sf2 extension for soundfont files is supplied as well if it isn't specified explicitly in the soundfont filename.
- Bugfixes: Fixed a memory leak on fluidsynth synths and settings when a fluid~ object is deleted. Also, program changes are now correctly translated between Pd and Fluidsynth. Note that the program numbers are 1-based in Pd and 0-based in Fluidsynth, which wasn't taken account of previously.
- A few cosmetic changes to help and error messages. Mostly we just turned some post() calls into proper error messages, so that the fluid~ objects causing an error, such as not being able to find the soundfont file, can be tracked down more easily.
- The help patch has been updated and converted to pddp format. The accompanying simple_onthego_synth patch has been updated as well, as it was outdated and failed to work, and the midi-input.pd abstraction from https://bitbucket.org/agraef/pd-smmf is included. We still don't include any soundfont files to conserve space, but both the help and the simple_onthego_synth patch now have clickable links to Tim Brechbill's small (~6MB) GM soundfont, and the extensive soundfont list in the Musescore manual.
### Backwards Compatibility (a.k.a. "Legacy" Mode)
In "legacy" mode, which is the default, the object is 100% backwards-compatible (except for the soundfont file search, which wasn't supported at all previously), so that existing patches will continue to work without any changes.
### SMMF Mode
In SMMF mode, which is invoked with the new `-smmf` option (used either as a creation argument, or with the `init` message), the SMMF message format can be used to denote MIDI messages. Legacy messages still continue to work in SMMF mode as well, except the `note` and `bend` messages which are used in both formats with the same argument count but different argument order, so SMMF mode overrides the legacy messages. However, the corresponding shortcuts `n` and `b` of the legacy format still work even in SMMF mode.
**Rationale:** SMMF offers the following advantages over the legacy message interface that fluid~ currently uses:
- It covers all MIDI voice messages, as well as system exclusive messages. Note that sysex support is particularly interesting because it allows to pass tuning data using sysex messages following the MIDI Tuning Standard (MTS), which fluidsynth readily supports.
- It enforces a close 1-1 correspondence between the Pd MIDI objects and the message format (it uses the same basenames as message selectors, and has the arguments in the right order to easily interface with the Pd MIDI objects).
- It is is readily supported by some helper abstractions (midi-input.pd and midi-output.pd, available at https://bitbucket.org/agraef/pd-smmf; the former is now also included with the fluid~ external).
- Last but not least, it is compatible with [pd-faust](https://agraef.github.io/pure-docs/pd-faust.html) and [pd-faustgen2](https://github.com/agraef/pd-faustgen) which makes it very easy to integrate Faust- and soundfont-based synthesis in Pd.2.15.1Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/569Enabled visual feedback when clicking on the empty symbol gatom to edit its v...2020-10-06T19:10:27ZIvica BukvicEnabled visual feedback when clicking on the empty symbol gatom to edit its value* Before, empty symbol gatom had no feedback when being clicked on and one had to start typing trusting that the object is indeed properly activated.
* Now, the object draws ... as soon as an empty (and only empty) symbol gatom is selec...* Before, empty symbol gatom had no feedback when being clicked on and one had to start typing trusting that the object is indeed properly activated.
* Now, the object draws ... as soon as an empty (and only empty) symbol gatom is selected, so that it has text to highlight thereby letting the user know that the object is ready to receive their input. In case the symbol gatom already has content, then that content gets highlighted which serves the same purpose.
* This does not affect the float gatom.2.15.1Ivica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/808Draft: Autocomplete feature2022-08-14T06:35:10ZGabriela BittencourtDraft: Autocomplete featureThis adds a dropdown menu with completions from the completion index
when the user creates a new object, message or comment, and starts
typing. Note that this index is initially populated with objects from
the search index of the help br...This adds a dropdown menu with completions from the completion index
when the user creates a new object, message or comment, and starts
typing. Note that this index is initially populated with objects from
the search index of the help browser. As the user types object names,
arguments, messages and comments, they will be added to the completion
index as well.
Entries from the menu can be chosen with the cursor up and down
keys. The enter key can then be used to select an entry and insert the
corresponding completion. Alternatively, clicking with the mouse also
selects an entry.
NOTES / TODO:
This is a very first implementation of autocompletion for purr-data, and
as such it still has a few minor quirks and shortcomings:
- Help index completions: Completions from the help browser's index will
only be available once that index has been built. By default, this
happens when the help browser is first launched. However, you can
change this so that the help index is automatically created when
purr-data launches, by ticking the corresponding checkbox in the GUI
preferences. This will make sure that completions from the help index
are always available, even before launching the help browser for the
first time.
- Prefix matches: As shipped, completions will encompass all matches of
the typed text, even within an index item. There is an option to
select prefix matches only in the code of the search_obj() function in
pdgui.js. Currently changing the code is the only way to get this
behavior; there should probably be a checkbox in the GUI preferences
to make this easier.
- Tab completion: There is no binding for the Tab key in order to select
a default completion yet, so currently you have to use the cursor keys
and enter or the mouse to select a completion. This will hopefully be
added in the future.
- Stale completions: At present, there is no way to remove "stale"
completion entries, such as obsolete entries from the help index, or
manually typed completions which haven't been used for a long
time. There should probably be a way to do this in a (semi-)automatic
fashion, but at present the completion engine offers no support for
this.
- Disabling option: At this MR the user won't have the option of disabling
the autocomplete feature. May be nice to have a checkbox in the GUI
preferences to enabling and disabling this feature.
**Note:** This MR shall be accepted after the MR !798 and a proper re-basing.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/798Add Related objects in the search index2022-02-06T22:41:31ZGabriela BittencourtAdd Related objects in the search indexFor all objects that have a "related objects" field in its meta data, the list of related objects will be added to the help index and will be displayed along with its description in the help browser. For related objects which can be loca...For all objects that have a "related objects" field in its meta data, the list of related objects will be added to the help index and will be displayed along with its description in the help browser. For related objects which can be located on the help path (given the help browser's search scope set in the gui preferences), the object will also be clickable, and open the corresponding help patch when clicked.
Moreover, objects will be listed in the search results if they have the search term as a related object. For instance, a search for 'pulse' will also list 'metro' because 'metro' has 'pulse' as a related object. Note that depending on the actual meta data, relatedness isn't necessarily symmetric. E.g., 'pulse' doesn't list 'metro' as a related object in turn and thus a search for 'metro' will *not* show 'pulse' in the search results, even though 'pulse' is related to 'metro'.
This feature makes it necessary to rework on the index creation process:
First, we'll iterate over the default hierarchy and the help path (if enabled) determining names and locations for each patch - this is important to resolve related object references meta data.
Secondly, we'll iterate over all index entries constructed in the previous step, adding all the available meta data, including cross references to related objects. When this step finishes, index construction is completed and the index cache is written to disk.
**Note:** The help browser now narrows indexing to just the -help.pd patches, while previous versions would index all .pd files. This may be subject to review (and is easy to change back if needed), but the new indexing scheme is faster and produces less noise in the search results (i.e., you won't see any helper abstractions or other patches which just happen to be bundled with the help patches), which actually seems preferable.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/795Draft: Replace elasticlunr.js with fuse.js2022-02-06T22:44:25ZGabriela BittencourtDraft: Replace elasticlunr.js with fuse.jsChange the search engine, from elasticlunr to fuse. Fuse is a powerful
search engine used worldwide and constantly upgraded. It uses a fuzzy
finder -- test searching for "metro", writing "mitro" and you'll see
that the engine is capable ...Change the search engine, from elasticlunr to fuse. Fuse is a powerful
search engine used worldwide and constantly upgraded. It uses a fuzzy
finder -- test searching for "metro", writing "mitro" and you'll see
that the engine is capable of finding.Albert GräfAlbert Gräfhttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/766debuild: Adjust the arm64 build to use Maurits Lamers' nwjs package.2021-04-19T10:45:29ZAlbert Gräfdebuild: Adjust the arm64 build to use Maurits Lamers' nwjs package.This is a followup to !732 which further adjusts our debuild machinery so that arm64 packages can now be built successfully on the OBS. An exemplary Debian 10 arm64 build is available [here](https://build.opensuse.org/package/show/home:a...This is a followup to !732 which further adjusts our debuild machinery so that arm64 packages can now be built successfully on the OBS. An exemplary Debian 10 arm64 build is available [here](https://build.opensuse.org/package/show/home:aggraef:purr-data-git/purr-data) (go to "Download package", choose "Debian" and then follow the instructions; or you can just grab the arm64.deb package right here: https://download.opensuse.org/repositories/home:/aggraef:/purr-data-git/Debian_10/arm64/purr-data_2.16.0+git4826+48ca6e4d-1_arm64.deb).
This build uses the only arm64 build of nw.js that seems to be available *anywhere* right now, which is a build of nw.js 0.23.7 done some time ago by Maurits Lamers, available here: https://github.com/LeonardLaszlo/nw.js-armv7-binaries/releases/tag/v0.23.7
I haven't tested the resulting binary yet. But at least it builds on the OBS now. I invite anyone with an arm64 Debian 10 system to give it a go.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/753pddplink: handle symbol input on the 1st inlet.2021-04-15T02:06:27ZAlbert Gräfpddplink: handle symbol input on the 1st inlet.As discussed on the mailing list, it's useful to allow symbol inputs (other than bang) on pddplink's inlet, to make it easier to invoke pddplink on a variable symbol (filename, patch, URL) value.
Note that for backward compatibility, a ...As discussed on the mailing list, it's useful to allow symbol inputs (other than bang) on pddplink's inlet, to make it easier to invoke pddplink on a variable symbol (filename, patch, URL) value.
Note that for backward compatibility, a dummy filename argument is still needed. Please check the updated help patch for details and an example.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/739Add canvas-local bendin and zoom flags.2021-04-10T18:27:57ZAlbert GräfAdd canvas-local bendin and zoom flags.This adds canvas member variables and corresponding options for the `declare` object, so that the global (user) zoom and legacy bendin flags can be enabled and disabled separately for each canvas.
This was proposed (and deferred) earlie...This adds canvas member variables and corresponding options for the `declare` object, so that the global (user) zoom and legacy bendin flags can be enabled and disabled separately for each canvas.
This was proposed (and deferred) earlier in !561 (which see for the previous discussion and rationale), but the original branch seems to be gone, so I've rebased it on the current master and pushed it again.
Jonathan, I really hate to revive this old MR which we discussed at length already. But we're 6 months on, we don't have author-centric zoom yet, and I'm still facing the same issue that prompted me to create this MR in the first place. As long as we don't have author-centric zoom yet, can we at least implement this as a stop-gap solution, please?Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/732Arm64 Debian build fixes2021-04-14T17:22:31ZAlbert GräfArm64 Debian build fixesThe goal of this MR is to have Purr build correctly on the OBS for arm64 Debian systems (Buster a.k.a. Debian 10 for now), so that it can be run on Chromebooks with a true 64 bit Linux subsystem, but it's not quite there yet. The problem...The goal of this MR is to have Purr build correctly on the OBS for arm64 Debian systems (Buster a.k.a. Debian 10 for now), so that it can be run on Chromebooks with a true 64 bit Linux subsystem, but it's not quite there yet. The problem is that we don't have any proper arm64/aarch64 packages for nw.js yet, so we're using Leonard Laszlo's armv7 (32 bit) packages instead.
**What works:** The package builds correctly and all regression tests pass. So everything but the gui works.
**What doesn't work yet:** The final packaging fails during the `dpkg-shlibdeps` phase, when dpkg detects that it can't find the 32 bit system libraries needed to run nw.js.
I guess that the package would work fine if I knew what 32 bit library dependencies are needed to make the armv7 version of nw.js work on an arm64 Debian system.
Jonathan, can you help with this? I know that you're running Purr on your Chromebook, is that a 32 or 64 bit Debian that you're running there? Maybe what I'm trying to do just isn't possible, so running Purr only works on 32 bit arm Debian systems for now?Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/5752.15.0 release candidate2020-09-30T22:31:59ZAlbert Gräf2.15.0 release candidateReplaces !574. Fixes #449.
This includes my own !572 and !571, Ico's !554, !557, !563, !567, and !568, and last but not least Guillem's !560. All fully merged, with merge conflicts fixed and with proper merge commits included.
These ar...Replaces !574. Fixes #449.
This includes my own !572 and !571, Ico's !554, !557, !563, !567, and !568, and last but not least Guillem's !560. All fully merged, with merge conflicts fixed and with proper merge commits included.
These are all finished, have been tested very extensively, and are as ready as they'll ever be without getting them out in a release.
All that remains to be done is merge this MR to master and tag the release.
**NOTE:** Once this is merged, !572 and !571, !554, !557, !563, !567, !568, and !560 will all effectively be merged as well and so can be closed (unless Gitlab discovers that on its own; Github is clever enough to do this, but I'm not sure about Gitlab).Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/574Draft: 2.15.0 release candidate2020-09-29T20:35:15ZAlbert GräfDraft: 2.15.0 release candidateThis includes my own !572 and !571, Ico's !554, !557, !563, and !568, and Guillem's !560. All fully merged, with merge conflicts fixed and with proper merge commits included.
These are all finished, have been tested very extensively, an...This includes my own !572 and !571, Ico's !554, !557, !563, and !568, and Guillem's !560. All fully merged, with merge conflicts fixed and with proper merge commits included.
These are all finished, have been tested very extensively, and are as ready as they'll ever be without getting them out in a release.
All that remains to be done is merge this MR to master, bump the version number and tag the release.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/570WIP: footils knob overhaul2020-10-02T00:52:48ZIvica BukvicWIP: footils knob overhaulComplete overhaul of the knob object to ensure it draws and behaves correctly. Everything should work with one notable exception: the logarithmic displacement is permanently disabled as it never quite worked the way it should.
**Please ...Complete overhaul of the knob object to ensure it draws and behaves correctly. Everything should work with one notable exception: the logarithmic displacement is permanently disabled as it never quite worked the way it should.
**Please note this merge request does not include any of the improvements that are to be introduced in the !544, so the !544 will very likely depend on this one moving forward.**Ivica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/562tar_em_up.sh: dpkg-deb configuration via environment variable2020-09-22T17:56:57ZAlbert Gräftar_em_up.sh: dpkg-deb configuration via environment variableThis allows the path and name of the `dpkg-deb` tool to be configured via the `dpkg` environment variable when invoking the tar_em_up.sh script.
This should rarely be necessary, but there's one important use case I need it for: *disabli...This allows the path and name of the `dpkg-deb` tool to be configured via the `dpkg` environment variable when invoking the tar_em_up.sh script.
This should rarely be necessary, but there's one important use case I need it for: *disabling* the Debian package build when invoking tar_em_up.sh via make, which runs tar_em_up.sh with automatic target detection (-T). With automatic target detection, tar_em_up.sh will try to build a Debian package on any Linux system if the `dpkg-deb` tool is available, no matter whether the system is actually Debian-based.
On the Manjaro system which I use to do my local package builds, I do have the Debian packaging tools installed, because I also create Debian source packages for the OBS builds there. But I have no use for the binary Debian packages that tar_em_up.sh will then create when building Purr Data locally with make, in fact the deb creation slows down the build near the end quite a bit, which means wasted time. So now I can just set `dpkg` to `disabled` (or anything else which isn't executable) when running make to force tar_em_up.sh to skip the Debian packaging.
Yeah that seems like quite a lot of hassle to just skip the creation of those unwanted debs. ;-) But I do save quite a lot of build time that way, that's why I need this.
On other platforms than Linux, tar_em_up.sh will just ignore this setting. On Linux, normal builds won't be affected either (unless you have the `dpkg` environment variable set, which shouldn't normally be the case).Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/561Draft: Canvas-local options2021-04-03T13:00:02ZAlbert GräfDraft: Canvas-local optionsJonathan, a while ago you asked for a canvas-local version of the global -legacy-bendin flag, which would facilitate porting vanilla patches involving bendins. Well, here it is. :) You can now just add a `declare -bendin 1` object to a p...Jonathan, a while ago you asked for a canvas-local version of the global -legacy-bendin flag, which would facilitate porting vanilla patches involving bendins. Well, here it is. :) You can now just add a `declare -bendin 1` object to a patch to have all bendin objects operate in vanilla-like fashion (using the zero-based range instead of signed bendin values, which is our default). Conversely, if you have `-legacy-bendin` in your startup flags to enable vanilla bug compatibility by default, you can override this in a patch with `declare -bendin 0` to enforce the pd-l2ork default range.
While I was at it, I did the same for the global sys_zoom option in the gui prefs, which enables saving and loading zoom factors in a patch. `declare -zoom 1` now ensures that the zoom level is saved and restored with a patch, even if the global option is off, and `declare -zoom 0` does the opposite.
Note that I used the declare option rather than a message to the canvas for these options, as `declare` is more convenient and easier to remember, and in any case just seems to be the right way to manage these kinds of canvas-local flags. Other canvas-local flags could be handled in an analogous fashion in the future (you might also want to redo your hex color compatibility option that way, so that it could be a canvas-local setting).
Finally, as a bonus I also added a little cosmetic improvement to declare's error reporting, so that an unrecognized option such as in `declare -junk 1` will give a proper error message like:
~~~
declare: -junk: unknown declaration
declare: 1: unknown argument
~~~
instead of the weird-looking message below:
~~~
declare: -junk: unknown declaration
declare: : unknown declaration
~~~
Note the empty flag that declare is complaining about there, which is actually the numeric option argument. Vanilla does it the same way, but I'd say that my fix in rev. 8409f7d9512716c36014cdc75ebffd6e8e2f9e0b makes that message look much more sensible and meaningful. ;-)Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/557Disable passing of key presses globally when an object grabs focus via glist_...2020-09-30T21:43:04ZIvica BukvicDisable passing of key presses globally when an object grabs focus via glist_grab* This means an object has requested exclusive focus
Jonathan, please **merge !554 first** so that we can then rebase and fix a trivial conflict in this MR, and also fix up a glist_grab() call in !554 along the way. Relevant detail:
``...* This means an object has requested exclusive focus
Jonathan, please **merge !554 first** so that we can then rebase and fix a trivial conflict in this MR, and also fix up a glist_grab() call in !554 along the way. Relevant detail:
```
g_numbox.c:46:5: error: too few arguments to function ‘glist_grab’
46 | glist_grab(x->x_gui.x_glist, 0, 0, 0, 0, 0);
```
This line should become:
```
g_numbox.c:46:5: error: too few arguments to function ‘glist_grab’
46 | glist_grab(x->x_gui.x_glist, 0, 0, 0, 0, 0, 0);
```
(in other words, just add one more ",0 ")
This is the unfortunate side-effect of small independent fixes getting in the way of each other. Luckily this one is rather simple. LATER: check if !570 cleanly merges, since knob.c has the glist_grab call change as part of this patch, whereas !570 is an independent branch that does not have this change, so there may be a merge conflict.Ivica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/554Improvements to iemgui numbox (drawstyle, font sizing and dialog) (was: now c...2020-09-30T21:43:02ZIvica BukvicImprovements to iemgui numbox (drawstyle, font sizing and dialog) (was: now checks & autoadjusts height based on font size)* drawstyle ported from 1.x (formerly known as hide_frame option)
* font sizing applies only to the label, not the number value
* number value is automatically sized based on the numbox height
* improved dialog to accommodate the new ...* drawstyle ported from 1.x (formerly known as hide_frame option)
* font sizing applies only to the label, not the number value
* number value is automatically sized based on the numbox height
* improved dialog to accommodate the new option
* fixed sizing inconsistency when changing fonts (fonts only apply to the label, this was the case even before this patch), which is not how vanilla behaves but nonetheless is now a preferred way of operating, so when calculating the numbox width, we make sure it only uses the default font (DejaVuSans)Ivica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/551A simple bookmark feature for the help browser2020-09-18T21:07:28ZAlbert GräfA simple bookmark feature for the help browserHere is a last one for 2.14.1, then I'll be a happy camper and go away, so that you can prepare the release without further distractions from me. ;-)
With the loading times finally fixed in !548, I have one last gripe with the help br...Here is a last one for 2.14.1, then I'll be a happy camper and go away, so that you can prepare the release without further distractions from me. ;-)
With the loading times finally fixed in !548, I have one last gripe with the help browser, and that is the lack of customizability of the toc. I really want to be able to put my own favorite directories with help patches there. Whether it's a library that I use a lot, like mrpeach in the extra hierarchy, some examples I prepared for the students, or just stuff that I'm currently working on, I need to be able to bookmark these, and have the bookmarks stick around when I exit Purr and launch it again.
This MR implements just that, in the simplest and least intrusive way I can think of. I really want the help browser to stay as simple and accessible as it is, so the new bookmark feature stays out of the way if you don't want it, but is readily available with a keystroke or a mouse click if needed. So OOTB it mostly still looks as before:
![image](/uploads/a4de9394199f5e3f35eb0b04835e47b8/image.png)
Well, there's a new "favorite" icon there, and I also replaced the folder icon with something that matches up (I pilfered these from the KDE/Plasma Breeze theme, so they ought to be open-source). Moreover, I fixed the positioning of these so that they are nicely lined up with the search input now.
To add a bookmark, you go to the directory that you want to bookmark by any possible means (file browser, typing something like `extra/mrpeach` in the search box, etc.), and click on the favorite icon, or use the Ctrl+D keyboard shortcut. E.g., here I've selected and bookmarked extra/iemguts (note how the favorite icon lights up when a bookmark is set):
![image](/uploads/1c8387caad05e1c9fa07cde1ac221e75/image.png)
Of course, bookmarks can also be deleted again, either by clicking the favorite icon of a bookmarked directory, or by using the Shift+Ctrl+D keyboard command.
Bookmarks are shown in their own section at the bottom of the toc, after all the built-in sections. (The "Bookmarks" section title only appears if there are any bookmarks to show.) Here's my personal "Bookmarks" section, which I already populated with some bookmarks for illustration purposes:
![image](/uploads/80914903c7da731809b1e0eca2992b13/image.png)
As you can see, the browser also tries to pick up descriptions for the bookmarks if a corresponding *dirname*-meta.pd file is available in the bookmarked directory. Also, note that the lua-examples link there actually links to a folder in my Documents directory, so the links can point to any location that you can read, not just Purr's doc and extra folders. (I had to rework the main entry point to the search engine a bit to make that work; in particular, it does a proper check for directories typed into the search input now.)
Bookmarks are stored in ~/.purr-data (Linux, Mac) or ~/AppData/Roaming/Purr-Data (Windows) as a (nicely formatted) JSON file named bookmarks.json. That file is read whenever the help browser is opened, so bookmarks are persistent and can also be edited in a text editor when needed.
That's about it (read more about all the gory details in the commit messages). This is a really simple, but *very* useful facility (for me at least), and thus IMHO follows the spirit of how the help browser has always been working: simple, but powerful.
Tested only on Linux so far (hence WIP for now), but I think that I can complete testing on Mac and Windows today.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/548Help browser: add an index cache to speed up launch times.2020-09-17T17:40:26ZAlbert GräfHelp browser: add an index cache to speed up launch times.This is another one of my pet peeves, so it would be nice if it could still make it into 2.14.1. Added a cache to the index to considerably speed up launching the help browser. Tested on Linux and Windows so far, there I get speedups in ...This is another one of my pet peeves, so it would be nice if it could still make it into 2.14.1. Added a cache to the index to considerably speed up launching the help browser. Tested on Linux and Windows so far, there I get speedups in the 3-4x ballpark, depending on the OS and the number of indexed help patches (the more the better).
Features:
- Rebuilds and caches the search index if there is no cache yet, or if the cache is outdated (i.e., any cached directory or its parent was removed or modified since the cache was last created).
- Keeps track of the modification times of all cached directories of help files, as well as their parent directories, in order to determine when the cache is outdated. The parents are tracked to catch changes where new sibling directories are added. This may produce some false positives and still isn't 100% foolproof, but it is as close as we can get if we still want to achieve substantial speedups.
- Automatically rebuilds the index (and cache) from scratch, as soon as the help browser is relaunched after changes to the browser configuration in the gui prefs. So there's no need any more to relaunch Purr Data to have these changes take effect.
Both the index cache and the directory timestamps are maintained as ordinary text files with a straightforward syntax (basically colon-delimited csv) in the user's home directory. The files are located in configuration directories (.purr-data on Linux and Mac, AppData/Roaming/Purr-Data on Windows). Thus it's easily possible to modify these files with external tools (e.g., if we want to upgrade the file format in the future.)Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/538Add user-defined GUI presets.2020-09-15T04:34:17ZAlbert GräfAdd user-defined GUI presets.Yesterday, Joseph asked me about user-defined GUI presets, since he wanted to create his own "dark" style. Deriving your own css from existing style files isn't all that difficult if you just want to change the colors, and finding the ri...Yesterday, Joseph asked me about user-defined GUI presets, since he wanted to create his own "dark" style. Deriving your own css from existing style files isn't all that difficult if you just want to change the colors, and finding the right subdir in which to put those css files is also quite easy. But then the trouble begins, because Purr currently doesn't look for user-defined css files, and only allows the user to select the predefined gui styles in the prefs. So the only option right now is to manually edit that option list in the dialog_prefs.html file, which is inconvenient, and that file will be overwritten next time you update your urr Data installation.
Which is a bummer, because I'm sure that many developers and html/css buffs would like to play around with these GUI presets, and might well contribute some nifty new ones, if we only made this a little easier.
Which is what this MR is about. It discovers user-defined GUI presets (css files) in the css subdirectory of the gui folder, and adds them at the end of the corresponding dropdown menu in the GUI prefs. It is a convenience intended for users and developers who want to experiment with their own GUI styles.
The predefined presets are still hardcoded in the dialog_prefs.html file, and are always available (and displayed first in the dropdown menu). If the preset saved in the prefs doesn't exist anymore (e.g., because the user removed its css file), it will be ignored at startup and the default style will be used instead.
Note that this isn't entirely foolproof since the fallback may not exist if the user also removed the default.css file. But this could also happen previously when the css directory gets messed up, and in such a case the user simply gets what he or she deserves.
@jwilkes, honestly, I didn't plan for this one. ;-) But Joseph's inquiry reminded me that we need to do something to make it easier for the theme developers. As I've stuck my head quite a bit into the JS side of Purr lately thanks to Ico's contributions, I thought that I might as well give it a try, so there you go. Works well for me (I only tested on Linux so far, but I see no reason why it shouldn't work on the Mac or Windows and will of course test there later).Jonathan WilkesJonathan Wilkes