* Plugins tab in control panel display tabs using filter instead of hard coded list
* Update ControlPanelPlugins.tid
The two entries `[[$:/core/ui/ControlPanel/Plugins/Installed]] [[$:/core/ui/ControlPanel/Plugins/Add]]` were removed from list filed as per @Jermelon confirmation!
* Create SystemTag_ $__tags_ControlPanel_Plugins.tid
Update the SystemTags documentation tiddler
Mention TiddlyHost and link to some documentation on the
configuration options.
Also remove the TiddlySpot control panel and backups links since
they no longer work.
Notes:
* The last three fields are no use for TiddlySpot or TiddlyHost, but
it's possible that someone, somewhere is still using the old
store.php from Bidix's UploadPlugin, and would miss them if they
were removed.
I'd be happy to remove them in a future PR, if it's decided they
can be retired.
(If they were removed, I could delete the last row here:)
https://github.com/simonbaird/tiddlyhost/wiki/TiddlySpot-Saver-configuration-for-Tiddlyhost-and-Tiddlyspot
* It's still called "TiddlySpot Saver" which I think is fine for
now. TiddlyHost might use a different saving method in future
so keeping the existing name seems best.
* Make tag-picker work with every field
* Make EditTemplate/tags work with every field
* Make NewTiddlerTags and NewJournalTags selectable through tag-picker
* Update tag-picker Macro Docs
* Adds a name to the core plugin
* Make plugin listings consistently show "name: description"
* Make plugin listings consistently sort by title (thus grouping publishers)
* Add a missing plugin name
See discussion here: https://github.com/Jermolene/TiddlyWiki5/pull/4508#issuecomment-609671970
"Sub-plugins" are displayed within the dropdown of their parent plugin.
This is a more elaborate version of #4109. It doesn't address dependent plugins (yet), this is just about grouping addon plugins under their parent.
* 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.
* 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
* add PaletteManager
* add hint for "external" palette-names
* macro utility, for local \import only
this tiddler is never meant to be tagged $:/tags/Macro
contains only a colour macro which allows to call `<<colour "...">>` within a tiddler and get the parameter-name instead of the resolved color
used in the PaletteManager to reveal the original color below the color that just uses its color with the colour macrocall
example:
```
\define get-real-index(string)
\import $:/core/macros/utils
<$wikify $name="result" text="""$string$"""> <- does the "colour" macrocall, but the one that returns the parameter name
<<result>>
</$wikify>
\end
<$set name="color" value={{{ [{$:/palette}getindex[color-of-interest]] }}}>
-> <<colour primary>>
<$wikify name="real-color-index" text="""<$macrocall $name="get-real-index" string=<<color>>/>""">
<<real-color-index>> -> primary
...
```
* transclude PaletteManager in snippets/paletteeditor
* transclude PaletteManager in core/ui/ControlPanel/Palette
* Update ControlPanel.multids
* add style for color inputs in PaletteManager
* Update PaletteManager.tid
* Update PaletteManager.tid
* add tooltips & aria-labels
* Update ControlPanel.multids
* Update PaletteManager.tid
* Update PaletteManager.tid
* Update PaletteManager.tid
* add focus capability to edit-shortcut widget
* focus the keyboard-shortcut inputs in the control panel
... there's no other reason why it could have been opened other than just pressing a shorcut ...
... saves the mouseclick
