Replies: 4 comments 14 replies
-
|
@tobiasdiez has had some very good points on plugins yes/no in the past, and I've generally stuck to his advice in this regard. Feel free to add some of your points here again, or link them, if you think that this is advisable, Tobias. However, that being said: I'm slowly starting to see that JabRef and Zettlr differ vastly in functionality. JabRef is a reference manager, and thus there is only so much that needs to be done. But over the past four years developing Zettlr, I have slowly but steadily come to the conclusion that writing text is much more complex and requires a lot of different tools, and many people have vastly differing requirements. I think reference managers can only do that much (and that is why I stick with only two plugins for Zotero, because everything else is simply not in the scope of a reference manager), but a writing app should offer much more stuff. That being said: Writing a plugin system is incredibly difficult, and thus we should do that extremely limited. Two very good suggestions for "trying this out" would be (a) a renderer plugin API, so that people can render whichever elements they like within the app, and (b) a language server API so that people can incorporate external services for linting code, spellchecking, and what not else. That might keep the effort manageable at least for now. New features to the plugin API should only be incorporated after an insane amount of deliberation. With regard to security, there may be an easy way: invisible Browser windows. Each plugin could run in its own dedicated browser window. This would ensure that it's a fully autonomous process and can only interact within that sandbox. There would be just two things we need to remember: First, the So, it's worth a discussion, but we need to tread carefully. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that my experience with JabRef cannot directly be translated to Zettlr. Still the two major points of problems we had were:
These issues would also apply to Zettlr I think. One should also keep in mind that Zettlr's target group is more "non-technical" writers, and those normally don't have the knowledge to code plugins. Thus while for example the Zettlr community is larger, the pool of potential plugin writers is not necessary so. In my opinion, it make sense to have plugins if the community gets so big that they would for example jump in maintaining plugins if the original maintainer stopped doing so. For now I would advice to make it easier to contribute to Zettlr itself. Once @nathanlesage gets so many PRs about functionality that he actually doesn't want to have in the main repo, then I would say it's a good point to think about plugins. At the beginning they could also be just a collection of classes in a "plugins" folder in the main repo and giving users the possibility to switch them on/off. In this way one doesn't have to worry about extension store, security and backwards compatibility. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with your points.
One thing we could do to both ensure proper maintenance and prevent a bad reputation would be to enforce upper version constraints. As soon as we upgrade the plugin API, we could simply disable too old plugins and give out a notice. As long as the plugin API moves slower than the main app, this could be a compromise.
That's something that I would argue is already handled by having the Discord. It's easy to just drop a deprecation note there, and anyone developing plugins could look into that specific channel. As long as we're transparent that we're not taking hostages that might ensure both that plugins only get developed by people who want to commit to maintaining it. However, I see that it's a big undertaking. Therefore, I like the approach of limited plugins (only rendering or only linting for now). This way we could very gently introduce a plugin API.
I would argue when the point comes that I'm overwhelmed by PRs it's way too late to start thinking about Plugins. |
Beta Was this translation helpful? Give feedback.
-
|
Those said, is there a roadmap for limited plugin support? |
Beta Was this translation helpful? Give feedback.
-
|
At this point, I wonder how much it would make sense to offer a certain level of Obsidian API compatibility, just so that it's easier for some of the large number of Obsidian plugins to be ported… |
Beta Was this translation helpful? Give feedback.
-
|
Obsidian API compatibility would be super great! |
Beta Was this translation helpful? Give feedback.
-
|
Especially for something like the BMO-Chatbot |
Beta Was this translation helpful? Give feedback.
-
|
@AltayYuzeir among the now 1000s of Obsidian plug-ins there are many that would qualify for porting. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting discussion. After reading the pros and cons, and related thoughts, shared here, what comes to mind is a question. Obsidian seems to successfully implement a plug-in system, with a thriving community developing, maintaining and using the vast array of functionality these plug-ins provide. NotePlan (another MarkDown based knowledge, and task etc. management tool I use) also has a well established and excellent plug-in system. So I wonder ... is the notion of whether or not it's a good idea, whether the cons outweigh the pros, a case of over thinking this whole idea? I see no fundamental or overbearing disadvantage to allowing Zittlr to have expandable functionality through plugins. Other than the burden of having to significantly modify the underlying codebase to accommodate plugins. That will be a sizable task. But other than deciding if that's a task there is the time and resource to tackle, the wide questions of whether or not whether making Zettlr extension-capable is a good idea or not seems like a mute point to me. |
Beta Was this translation helpful? Give feedback.
-
|
Is this topic still under consideration or has it died a quiet death? |
Beta Was this translation helpful? Give feedback.
-
I tried Joplin, and although it has a lot of positive aspects, the one thing I dislike and ultimately was a deal breaker for me is the fact that notes are stored in an SQLite database. So, if ever you want to get hold of them you have to export them 1st. I prefer the Zettlr and Obsidian way whereby your notes are stored as notes so they are accessible from the system file explorer. |
Beta Was this translation helpful? Give feedback.
-
I did not know that. I've been looking for a light pkm for the past week, but like really suffering cause I wanted something lightweight and customizable. I was considering going to joplin but did not know you'd need to go though sqlite before accessing the files, bummer. And I got excited when I read a post in github soewhere that the author was thinking of porting zettlr to Tauri (this post was about 2 years ago). Electron really bloats the ram usage, Obsidian takes about 400 mb ram, (havent reinstalled zettlr in a while so cant compare), but if zettlr is not in tauri or anything lighter that electron and does not have the option for pluggins... well.... I'm not loving it... |
Beta Was this translation helpful? Give feedback.
-
|
Another option is QOwnNotes, which is customizable. But what puts me off, and it did for Joplin too, is the split panes for editing and reading modes. Neither Obsidian nor Zettlr have it, and that is such a nice thing. Typora is like Obs and Zettlr, but is not free. |
Beta Was this translation helpful? Give feedback.
-
are you refering to the WYSIWYG (What You See Is What You Get) that automatically renders the text in "pretty" format? |
Beta Was this translation helpful? Give feedback.
-
|
I disagree about Joplin. Having said that, I don't want go farther down this path because I don't think it is fair to discuss other apps on this Zettlr page. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I know that this is a big topic. But definitely one worth discussing. As Zettlr's userbase is constantly growing, so does the demand for new features. Unfortunately, not every feature request can make it into the app in the long run.
This is where extensions come in. They would allow anyone to easily customize the behavior of Zettlr to fit their needs (+ share it with others). Other benefits:
A few aspects that came into my mind regarding the implementation of an extension infrastructure:
I might have missed some aspects, and I also don't know the effort required for this endeavor. That's why I thought it might be a good idea to open a discussion. So that we have a central place to talk about this topic (maybe there is already one?).
Beta Was this translation helpful? Give feedback.
All reactions