Previously, it was not possible to deselect entries by editing the tiddler $:/generated-list-demo-state used in the final example of the SelectWidget docs
* First pass at dynamic loading/unloading
* Show warning for changes to plugins containing JS modules
* Use $:/config/RegisterPluginType/* for configuring whether a plugin type is automatically registered
Where "registered" means "the constituent shadows are loaded".
* Fix the info plugin
The previous mechanism re-read all plugin info during startup
* Don't prettify JSON in the plugin library
* Indicate in plugin library whether a plugin requires reloading
* Display the highlighted plugin name in the plugin chooser
And if there's no name field fall back to the part of the title after the final slash.
This fixes the HTTP request sent to gitlab that is meant to see if the
target file already exists. It did not follow the official gitlab v4 api
documentation. That documentation dictates both `path` and `branch` to
be passed via corresponding GET parameters.
This fixes a bug in #3634, and refines the logic so that the warning is only given if the incoming tiddler exists as a shadow tiddler. (In my case I have several draft core modules inactive in my notes wiki and they were erroneously suppressed from the upgrade).
* add "delayed" option to tm-focus-selector message
this delays the focussing for the time of the animation duration if delayed="yes" or delayed="true"
this is useful when navigating the story river up and down with keyboard shortcuts and the shortcuts focus the title input if a navigated tiddler is in edit mode -> navigation doesn't jump but stays smooth
* Update rootwidget.js
* Update WidgetMessage_ tm-focus-selector.tid
* add preventScroll="true" tip
* Transform GitHub saver to work with GitLab as well
You can choose which provider you want to use, the data is given in the
same place.
I tried to avoid code duplication, so service providers' unique
properties are in separate files, the settings of the selected provider
are loaded.
In two fields I am not sure that it fits into the current structure:
* module-type: gitservice
Which module is a `gitservice` type, it will be listed in the
drop-down menu.
* default-api-url: https://gitlab.com/api/v4
The default URL to access the provider's API.
This is just a sketch, not a final version, suggestions for modification
are welcome!
* Rename saver from GitHub to GitService, update docs
* Split GitHub and GitLab to separate savers, apply common lingo
Sadly, it doesn't seem to make much sense to search for common parts in
the code, because there might be a Git service that is very different
from the GitHub API (such as BitBucket). Therefore, I feel that Git
savers are not able to share other than the translations.
I deleted the defaults values from the translations and set it to the
text entry because they should not depend on the translations.
* Add more information about the password field
It is not clear how to create a personal access token, thus added a link
to the help pages. In addition, GitLab only accepts personal access
token, GitHub also accepts the password, so I made this clear.
* Extract commit message to lingo
* Fix indentation
* Use improved base64 encoder
Fix conflict with a06acc4eb8
Fixes#4082
This version removes selective updating of the tag index, instead completely clearing the index on each update. I'm investigating restoring that optimisation.
* Remove the th-renaming-tiddler hook from navigatior.js
The hook is invoked in the renameTiddler function which would cause the same hook to be called twice, and the version in the navigator widget didn't have the correct inputs and return value according to the documentation.
* Make it so that the th-renaming-tiddler hook isn't called twice
by removing it from the navigator.js file
The test rig previously used a simplified implementation of shadow tiddlers which broke with the new indexing engine. There was also a problem that made that even if indexers were disabled they were still initialised.
This PR fixes both problems, in preparation for fixing #4082
See discussion at https://groups.google.com/d/msgid/tiddlywiki/526754d5-8786-49cd-aaa1-c77311670116%40googlegroups.com:
The history here is that in v5.1.14 we added an "actions" attribute to the checkbox widget that specified an action string to be specified whenever the state of the checkbox changed. The same action string is executed regardless of whether the checkbox was checked or unchecked.
Then in v5.1.16 we merged https://github.com/Jermolene/TiddlyWiki5/pull/3182 which added the "uncheckactions" attribute. The difference between the two is that the uncheckactions are only executed if the checkbox is unchecked. The main "actions" attribute is executed before any actions in "uncheckactions", which makes it possible to arrange things so that the "actions" attribute sets things to the checked state while the "uncheckactions" attribute overwrites those changes to set things to the unchecked state.
In retrospect, it would have made more sense to have also added a "checkactions" attribute that was executed only if the checkbox was checked. I'll investigate adding it for v5.1.20.
