- Sep 21, 2020
-
-
-
* Ability to edit incrementally with text and mouse (e.g. backspace erases only one digit) * Better use of hte '>' as a cursor * Key presses start a new number from scratch unless user has dragged a number and established a new number by dragging, or unless they shift+clicked when they gained focus on the numbox, in which case numbox will allow for user to append to the existing value * Shift + backspace erases everything, while backspace erases only one character * When there are no digits entered, the value reverts to 0 * Pressing return/enter removes the trailing '>' until a key is once again pressed * Changing values with mouse also removes the trailing '>' * Resizing across only x and y axes now works (vertical resize still inevitably affects the width due to change in character length, but it now never exceeds the x value it started with during that particular click'n'drag action)
-
* 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
-
- Sep 19, 2020
-
-
Jonathan Wilkes authored
-
Albert Gräf authored
This uses findAndReplaceDOMText(), which apparently looks for case-sensitive matches, but the search text entered by the user is *always* converted to lowercase. This means that mixed case search terms just won't be found, which is bad. (E.g., try searching for "GEM" in the toc to see this bug in action.) Fixed by just removing the call to toLowerCase() on the search text, case-sensitive searches now work as expected, problem solved.
-
Albert Gräf authored
This resolves a long-standing bug (the relevant code is 4-5 years old). While it is just one little missing check in the keyboard event handler, which is surely just an oversight, this has the dire consequence of breaking navigation with the Tab key. - The root cause for this issue is in the document.body event listener callback, where we always reset the focus to the search text input if there's *any* keyboard input (other than a LF or CR on the file browser and bookmark buttons) while the focus is on something else (such as an item in the toc or in the search results). The intention there surely was to enable the user to just start typing *anywhere* in the dialog, which is convenient, but has the unwanted side-effect of breaking Tab navigation (as well as the cursor keys). - The fix is simply to *not* reset the focus if the key event is the Tab key. Besides Tab, we also treat the modifier and cursor keys in the same fashion, so that these will be handled on the spot rather than being forwarded to the search text input. By these means, you can still start typing your search terms from anywhere in the dialog, but navigation with Tab and Shift+Tab and the cursor keys now also work as expected. - Also, why is the div holding the toc items created again and again for each item in display_toc()? I moved the corresponding statement, div = document.createElement("div"), right before the toc.forEach() loop now, which I think is where it really belongs.
-
- Sep 18, 2020
-
-
Jonathan Wilkes authored
-
Albert Gräf authored
This reverts commit 12bd57bd, reversing changes made to e9d38d23.
-
Jonathan Wilkes authored
-
Jonathan Wilkes authored
-
Albert Gräf authored
Disable the bookmark icon in situations where bookmarking isn't possible (search results, doc directory).
-
Albert Gräf authored
- Use canonical paths just about everywhere in the help browser. We want to stick to portable, normalized paths as much as possible, to avoid funky Windows path names, especially in bookmark files which should be portable across different platforms. - Fix the generated click_toc() call in display_toc(); we need to properly stringify the callback argument there. - Update the search field after opening a directory via the file browser, so that the search text matches the directory display. Is there a reason that we're not already doing this? I don't think so, because we're doing the same when clicking a link in the toc. - Prevent the doc directory from being bookmarked. There's nothing interesting to see there anyway (just subdirectories, no help patches). Also, since the toc lives there (in a virtual sense, i.e., the current browser directory is set to this directory whenever the toc is displayed), we also avoid an interesting race condition which arises if we try to update the toc while we're displaying it. (This doesn't seem to happen on all platforms, but I've seen it on the Mac at least.) - Fix a purely cosmetic issue with the bookmark entries. (Entries with a null description were stored as is and then written to the bookmarks file. Now the description is just omitted in that case.)
-
- Sep 17, 2020
-
-
Albert Gräf authored
This takes the form of a little bookmark icon to the right of the file browser icon. Just the plain icon indicates that the current directory hasn't been bookmarked yet, and that clicking on it will bookmark it. If you do this, a little red cross appears on the icon, which reminds you that the directory has been bookmarked, and that clicking on the icon will remove the bookmark again. Note that in general a directory may have been bookmarked multiple times, by using the keyboard shortcut (Ctrl-D). In this case the red cross will stick until the last instance of the bookmark has been removed. The icons come from the Manjaro KDE Breath theme (a variation of the KDE Breeze theme), and we also replaced the folder icon with a matching icon from the same theme. Thanks are due to the Manjaro and KDE teams! While we were at it, we also fixed the vertical alignment of the icons with respect to the search field, they are properly aligned to the middle now.
-
Albert Gräf authored
The Ctrl+D keyboard command in the help browser adds a bookmark for the current browser directory, Shift+Ctrl+D removes it again. Note that the same directory can be bookmarked multiple times (using Ctrl+D), in which case the same number of delete commands (Shift+Ctrl+D) are required to delete all instances of the bookmark again; at any time, the oldest instance will be removed first. This also provides a (really simplistic) way to reorder bookmarks, since you can re-add an existing bookmark and delete its older instance afterwards, which effectively moves the bookmark to the end of the bookmarks section. It goes without saying that this becomes rather laborious if you have to manage a lot of bookmarks, so in that case you might prefer to just edit the bookmarks file (see below) in your favorite text editor instead. Bookmarks are shown in their own "Bookmarks" section at the bottom of the toc, after the built-in toc sections. The "Bookmarks" section title will be visible only if there are any bookmarks. As with the built-in toc items, clicking on the title of a bookmark takes you to the corresponding directory, which may be in the doc or extra hierarchy, or anywhere else on your hard disk. If a <dir>-meta.pd file in pddp format is present in the bookmarked directory, the browser will try to extract title and description from the NAME and DESCRIPTION tags in that file, otherwise it simply uses the basename of the directory as title and leaves the description empty. The bookmarks are stored permanently on disk as a JSON file in the users home directory, named .purr-data/bookmarks.json on Linux and the Mac, and AppData/Roaming/Purr-Data/bookmarks.json on Windows. This file is read each time the help browser opens, so the bookmarks persist across program invocations, and you can even edit the file manually and reopen the help browser to make it pick up your changes while Purr Data keeps running.
-
Jonathan Wilkes authored
-
Jonathan Wilkes authored
-
Ivica Bukvic authored
-
Jonathan Wilkes authored
-
Jonathan Wilkes authored
-
Jonathan Wilkes authored
-
Ivica Bukvic authored
-
Sam Thursfield authored
This saves time and bandwidth. Closes #668
-
Sam Thursfield authored
Previously we would redownload the tarball in all cases, saving it as nwjs-*.tar.gz.1 or similar.
-
Sam Thursfield authored
This helps the CI to discover the necessary nw.js tarball while keeping the logic in one place.
-
- Sep 16, 2020
-
-
Sam Thursfield authored
This allows the CI to cache the downloaded tarball. Developers can manually delete it if needed.
-
Sam Thursfield authored
This causes tar_em_up.sh to download an older version of nw.js suitable for OSX 10.8.
-
- Sep 15, 2020
-
-
Albert Gräf authored
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.)
-
Guillem Bartrina authored
-
- Sep 14, 2020
-
-
Jonathan Wilkes authored
-
Jonathan Wilkes authored
-
Jonathan Wilkes authored
-
Jonathan Wilkes authored
-
Guillem Bartrina authored
add an alert system that notifies the user of the existence of unsaved edited instances of the abstraction he is editing or about to edit
-
Albert Gräf authored
-
Albert Gräf authored
Our 32 bit Windows installer currently installs some binaries (dll and exe files) in the Windows system32 directory. This is unnecessary (all required dlls are already in the program bin directory where pd.exe will readily find them), and actually a nuisance, since we currently don't remove some of the dlls in system32 again when uninstalling, causing a lot of inconvenient prompts from the installer when upgrading or reinstalling. If the user wants to run cyclist, pdreceive, or pdsend from whatever command line he uses, he can easily add the program bin directory to PATH himself. That's much better than having our installer pollute the system32 directory. The mingw64 build already does it that way, here we simply apply the same fixes to the mingw32 build.
-
- Sep 13, 2020
-
-
Albert Gräf authored
-
Albert Gräf authored
-
Jonathan Wilkes authored
-
Jonathan Wilkes authored
-
Jonathan Wilkes authored
-