Regarding Feature Requests for Vertical Tabs: UI Customization and Integration with Community Plugins #113
oxdc
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
Thank you for your ongoing support of the Vertical Tabs plugin! I’m thrilled to see how our community has grown and evolved. With the increasing number of feature requests and user feedback, I truly wish I had enough time and energy to meet all expectations and deliver the best experience for everyone.
As you may know, Vertical Tabs started as a personal project to help me organize my workspace in Obsidian. As the sole maintainer juggling a busy schedule, I’ve decided to prioritize improving core functionalities and delivering exciting new features. Consequently, I’ve chosen to defer the integration of certain community plugins—especially those related to UI customizations—to their respective authors. Below is an incomplete list of such requests:
Why this decision?
There are several factors that led to this approach, with the most significant being technical challenges:
1. Dependency on Plugin Internals
Many of these plugins are designed to enhance Obsidian’s built-in features, such as native horizontal tabs and the File Explorer. For example, Iconize and Iconic modify the icons in the File Explorer by directly altering its UI. From a user’s perspective, it might seem logical to ask, “Why doesn’t Vertical Tabs display the custom icons I’ve set using these plugins?”
However, under the hood, Vertical Tabs has no effective way of retrieving this information because it’s hidden within the internals of those plugins. Without a proper Application Programming Interface (API), Vertical Tabs would need to use intrusive methods to access such data, which is both error-prone and unsustainable.
2. Maintaining Compatibility
To support these plugins, I would need to reverse-engineer their internal workings, which are subject to frequent changes. If the authors of these plugins introduce breaking changes, Vertical Tabs would have to constantly adapt to every new release of every plugin. While Vertical Tabs has already heavily relied on the reverse-engineered internals of Obsidian, this maintenance burden would divert significant time and energy from core development.
3. Overlapping Features
There is also redundancy in the features provided by multiple plugins, such as Iconize, Iconic, and Supercharged Links, which all focus on customizing icons. Supporting multiple plugins for similar purposes would complicate the codebase and introduce performance overhead for all users, even those who don’t use these plugins. Moreover, enabling multiple plugins simultaneously could lead to conflicts.
A Path Forward
To enable seamless integration, a well-designed API is essential. Just as Obsidian provides the
getIcon
function to allow plugins like Vertical Tabs to access icon data, similar APIs could facilitate collaboration between Vertical Tabs and other plugins.Instead of Vertical Tabs adapting to these plugins, I propose a reverse approach: Vertical Tabs will expose functions that other plugins can invoke. For example, if Iconize is installed, it can call these functions to customize icons within Vertical Tabs. This incremental design ensures:
Next Steps
In the coming weeks, I’ll draft a design for the APIs or exposed functions of Vertical Tabs. I welcome your comments and suggestions during this process! Once these APIs are publicly released, you’ll be able to submit feature requests or pull requests directly to the GitHub repositories of the respective plugins.
Thank you for your understanding and support. I hope this approach will enhance both performance and the overall user experience.
Beta Was this translation helpful? Give feedback.
All reactions