Organize plugins in the settings menu using custom groups.
Assign groups to plugins; remove plugins from group.
View ungrouped plugins.
Add plugins to more than one group.
Sort plugins within a group in custom order.
Organize plugins in the settings menu using annotations.
Annotate individual plugins.
View, edit, toggle, and delete plugin annotations.
Annotate groups with a description.
View, edit, toggle, and delete group annotations.
Manage groups in the settings menu.
Create group.
View groups.
Search groups.
Edit groups.
Delete groups.
Sort groups into a custom order.
Assign groups to other groups as a sub-group.
Format and style groups.
Choose basic default display style via interface – font size, color, bold, italic.
Choose advanced default display style via CSS.
Customize display style of individual groups.
Reset custom styling: individually, bulk, all.
View the community plugin list and the installed plugin list in the settings menu by groups.
Sort plugins by alphabetical order (like Obsidian default), alphabetical groups, or custom group order.
Choose to display group annotations below the group name in the community plugin list or the installed plugin list (default: off).
Search installed plugins or groups in the community plugin list from a search box above the list.
Pin and unpin groups to the top of the list, ignoring sort order.
Unpin groups from within the list interface. Click the pin icon once to unlock the pin, then click it again to unpin.
Toggle setting: Unpin groups from within the list interface. Turning this off means that pinned groups can only be unpinned in settings, to prevent accidental unpinning.
Toggle setting: Display pinned group labels. Turning this off allows you to display individual plugins at the top of the plugin lists.
Save, re-use, and share groups with other vaults and users.
Export group data:
As a csv file
with or without configuration data
with or without group annotations
with or without plugin annotations
As a text file with a human-readable formatted list
With or without configuration data
With or without group annotations
With or without plugin annotations
Import group data:
From a plugin-generated csv file
From a user-generated csv file
From a text-based file with a formatted list
Allow other plugins to access, manipulate, and display groups.
Make groups and data accessible to themes and other plugins, such as plugin managers.
Feature List: Potential
Enable, disable, reload, or update plugins by group.
Mark plugins or groups in the settings menu with indicator icons.
Default icon set: shapes with color options
Add compatibility with icon management plugins to extend icon options.
Display indicator icons next to an individual plugin or group.
Define indicators.
Add a description to indicators.
Sort plugins by indicator.
Define indicator sort order.
Enable, disable, reload, or update plugins by indicator status.
Now you can easily manage your plugins and themes. Simply select the version you want or install unlisted versions from GitHub. You can also install beta version and switch back if necessary.
I am having related thoughts on the topic of how to better organize plugins and this is an impressive proposal and seemingly large in scope.
I would suggest much of the end goals could be accomplished by keeping structured notes about installed plugins within obsidian marked up with properties and tags to then group and organize in Obsidian just like any other note rather than build a very heavy bespoke interface with isolated preferences database and that would be a lot of work to replicate features already in the base application.
Whereas a plug in to help generate and upkeep one’s own personal plugin notes collection could potentially be implemented with very little ui surface area and therefore be faster to build and start using.
Managing plugins metadata as notes also makes possible to then collaborate on a shared vault of plugin notes as a community, if a common structured properties format could be established for community plugin notes.
I like the idea of having markdown notes for plugins. That fits in very easily with the main idea of this plugin: viewing plugins in a folder format (albeit in the settings interface).
Groups could be added and managed using a specific folder that contains “root” sub-folders with the group name, and each group folder has a sub-folder with the name of the plugin. Then, the plugin uses the group/plugin folder combination to customize the display of the plugin lists in the settings menu.
This means that you can store plugin documentation and annotations in md files, contained in the plugin folder.
The interface for “Plugin Organizer” can be made optional in this way, to accommodate different user workflows.
My own first steps in this direction so far are a functioning proof of concept plugin notes generator scripted up in python that parses the community plugins json file and uses a plugin note template to create a note for each of my installed plugins. It also parses the manifest from each plug in folder and adds those details to the notes in fields.
Adding other available plugins to the mix the template has block with github-query so plugins managed there can have an issues pane appear in my note for the plugin, which is nice.
What is not so nice is the wide variation of values I have found parsing fields of plugin manifest files, these could be a lot cleaner / more conformant than they are across the multitude of plugins.
Other ideas for plugin notes are version history / change log, personal and community ratings, plugin maintained status, download trends, any specific usage notes, track code audit history across versions and dependencies.
Unfortunately, I am not a programmer yet, but I am taking steps in that direction.
Re: Plugin Manifest: It sounds like Obsidian’s whole community plugin system needs standardization in multiple areas to help with compatibility. Searching for plugins is a terrible experience because of the lack of standard descriptions, tags, and filtering, for example. How to convince Obsidian the company to prioritize a standardization effort, though? A community-led effort would only go so far without support from the top.
My original goal was to create a spreadsheet of all of the plugins, so I could sort them by different criteria and build my knowledge system that way. There are 2000 plugins, but a given functionality usually has only one or two options. The quality of implementation varies widely, depending on how popular that functionality is.
So, not being a programmer, I figured the first step would be to define how I want a plugin to function and get feedback. And thank you very much for the feedback!
You are welcome, and thank you for starting the thread. It is a topic I have been thinking about and trying out ways to implement for a while. And I have seen similar posts on this topic in various forums before, which to me validates there is common need for some solution to exist.
Rather than spend a lot more time on my proof of concept in python, I have started a plugin project but its a lot of new learning for me working in typescript. I will update the thread if I make any progress developing it.
I didn’t think of it last night, but would it be helpful to see how other plugins implement a particular function in typescript? I can use my spreadsheet to find examples.
Yes thank you for the visualization, very well put together and thought through.
I think this is all quite achievable.
Here is a snapshot of plugin notes I created with a plugins dashboard page opened, where so far I have a few different dataviewjs queries returning different results tables of the notes. (in view are plugins I did not find a valid repo or author name for, but other tables follow below, such as enabled and disabled plugins)
I’m thinking in the direction where only creating and updating fields in plugin notes is the what the proposed plugin-notes plugin handles, and that all of the the outer summarizing and indexing meta-plugin notes as well as the internal specifics of the template plugin note will be up to the user to customize to their liking and particular needs.
Within that template plugin note customization many cool things should be possible. For example I expect we could use one of the various button implementation plugins to add an enable/disable toggle switch from each plug-in note.
