Closed sambbaron closed 6 months ago
Hello,
my approach so far has been to show some basics in the demo document. I would like to expand on that in the future with more/better examples but still of course it's far from this "community library".
Perhaps the easiest way would be to add this stuff to the wiki.
There are some issues:
But the biggest issue is that I don't really have time for this. So I would welcome this happening, but someone else would have to drive this.
Yeah, after writing this issue, I realized it was a big ask 😐. As I looked over old issues, I saw snippets that might be helpful to others, but if the API is still in flux, then perhaps not. The wiki does seem like a good option.
I've been thinking about this as well...
Adding more examples to the wiki would need at least some level curation, and that's much extra work. Another suggestion: Trilium users should write about their scripts and examples on their own blogs or gists or their own git projects, and we could link those from the Wiki. If any example becomes clearly specially interesting, it could be added to the wiki itself or to the default example notebook.
We could have guidelines requesting to make clear what version of trilium do these community scripts have been tested with.
Trilium's extensibility is one of its strong suits, it would be great to see what others are doing with it.
@zadam Github has discussions beta out now. How about adding one?
I'm willing to try this out on the side and PR if it works, but is it an idea you'd be OK with merging in theory @zadam ?
Pasted from #1328:
It would be interesting to have a git based "marketplace" repo which is by default hard-coded to some public repo that zadam owns, but maybe users could configure their instances to additionally point to private repos. Standard Notes has a similar system.
For example, maybe the repo's file structure could look like this:
/My Super Awesome Theme
/metadata.json
/... some file based representation of notes to import
/My Cool Render Note
/metadata.json
/... some file based representation of notes to import
Metadata could have information like markdown description, author, tags, etc.. As it's laid out above, there wouldn't be installing/uninstalling, just importing them somewhere into the tree. If Trilium ever has its own website someday, the marketplace could live on some subdomain and statically generate from this public git repository.
but is it an idea you'd be OK with merging in theory @zadam ?
I'm OK with merging this in theory, however I think it will be rather difficult in practice.
For the repo structure, looks good to me - I would essentially use the export/import ZIP format (but unzipped) - there's currently !!!meta.json
file with all the note metadata like attributes etc. There could be an extra metadata note with the author etc. as you mention.
Any updates? :)
For reference, some existing community code examples can be seen here: https://github.com/zadam/trilium/discussions/categories/show-and-tell
Also just for reference, some other community code can be found here: https://github.com/Nriver/awesome-trilium
Since we have various issues and discussions on this topic (#3293, #3238, #2969, #1328, #4567, #4603, #1873 ), let's consolidate the issues here and leave the discussion open at #1873 for more break-out discussions.
Relevant input from @zadam : https://github.com/zadam/trilium/discussions/1873#discussioncomment-642063 Also related: #4236
Current lists of various plugins/scripts/templates/etc:
A proper plugin system is something I briefly discussed with zadam but, I think it would be good to get more community input on how they expect it to work, from BOTH a user perspective and a developer perspective. Having that kind of input would help me in making a proposal (and potentially some PRs) to that end. So I'd love for people to describe their ideal system from either perspective.
I have some previous experience designing the extension system for BetterDiscord. And I say extension because like over there, Trilium could have both plugins and themes that include metadata like settings schema that allows end-users to easily customize the theme colors or a plugin's functionality.
Beyond the extension system itself, a centralized listing of all the ones available is of course always nice for end users. How that's handled is a whole other rabbit hole, but a discussion worth having nonetheless. The easiest of course would be to just maintain a list in a github repository or the wiki like we already have. It's not the most user friendly and it's difficult to get new ones added. It's also not obvious to find for users. The other extreme is to have a website dedicated to trilium (a la trilium.rocks) that maintains a listing where people can submit their own extensions. Obviously that has many issues of its own like malicious actors and such. But it could also have an API that the local Trilium client accesses to show an in-client listing of addons with an easy install button.
I have to think the solution for the library/store would have to be somewhere between those two extremes; the github wiki is not easily findable for users, and the advanced website is too much to maintain and setup for zadam. I don't know what that in-the-middle solution is, but hopefully someone else does :smile:
@rauenzi Have you seen https://hacs.xyz (The HomeAssistant Community Store)? It uses the git repository method and is IMO one of the best implementations I've seen. It defaults to a specific repository but allows you to define custom repositories or just search the known repositories which have been registered with HACS. The user can then search for any integrations registered with HACS and one-click install them. The installation page shows the related git repository readme along with some simple git stats. See the screenshots on the bottom of the hacs page i linked to.
It would be helpful to have a public library of community code for widgets, custom notes, css themes, hosting configurations, etc. This could expand community involvement and provide a showcase for potential new features.
Some implementation options: