Is there a way to change which buttons appear in the editor toolbar, or change their order? e.g. I personally don't use strikethrough or coding, but often use others including some plugin buttons and want those further to the left / in view when I shrink the window width.
When I toggle viewer / editor, in the markdown + viewer split view/mode, plugin button icons show correctly in the toolbar with the plugins' icons.
However in the single pane Viewer mode/view, the icons for the buttons for plugins changes to a generic gear icon. Perhaps a bug? Or is there a setting I'm not accessing properly? Logically, they should show in the Toolbar with the actual plugin icon as they do in split mode.
Understood, thank you, these are a design not a bug. Then both of these would be feature requests please to enhance the design!
Feature request 1 - customizing toolbar location fits with Joplin concept (just as one can customize general layout or an extensions toolbar in a browser).
Feature request 2 - WYSIWYG editor is part of Joplin's feature set, so logical if it could support plugins maintaining as much functionality as possible even in that view mode, which would include displaying the plugin icon not a gear. Note that plugins I use actually do continue to work in WYSIWYG view (such as Insert Date), it's just that their icon is shown as a gear making it difficult to select from multiple plugins without hovering over each.
I think you do not understand. Plugins that are written for the CodeMirror editor won't work in the WYSIWYG editor. This has nothing to do with Joplin but how the plugins are written.
However, making those toolbar icons to show up correctly or not show them at all is certainly a possibility. I think Laurent mentioned a while back that he's considering this. I guess there were always more pressing issues to work on.
True, I do not understand the coding and am writing from the perspective of a user about desired functionality, so I have moved this to Features and edited title to Feature requests.
As an aside, it would be nice if there were a voting system to inform coders and Laurent of community interest in features, such as a fixed number of votes per community member to allocate to a feature request, that could be reallocated.
Kindly note the plugins I am using most often, do work in WYSIWYG - I gave example above - Insert Date plugin - works well in all view modes, except for display of the plugin icon in the toolbar in WYSIWYG view.
The plan eventually, one day, is to allow customizing the toolbar by adding, removing or reordering buttons. I don't know when it will be done though and in the meantime custom css is indeed the way to go.
People can click on the and the more likes it gets the more people want a feature. This is usually how this works.
Right, but the WYSIWYG editor toolbar does not understand the info provided via the plugin API. As mentioned before, there are always more pressing issues (high priority bugs). But we are more than happy to accept a PR for this.
A little confused why a PR? The Pull Request guidelines suggest one per user at a time, and not PR but GSoC if issues is new after GSoC but as new user to Joplin and non-coder not sure how I can figure that out.
FYI the Joplin community invites feedback - one feedback, it seems a bit confusing where to provide it, compared to the feature requests/discussions on GitHub for KeePassXC. Discourse seems to auto-close a topic a month after last reply and I've found several repeats of the same topic (I recently opened one on multiple profiles/databases, as I couldn't like or continue last year's discussion of this).
The PR guidelines are for GSoC, which is over. Some of the guidelines (like tests) are also useful for PRs which do not fall under GSoC.
It was not directed to you directly but to anyone who reads the topic and wants to contribute.
Yes, resurrecting a topic after a few months or years is not very helpful. Some of the comments and even the topic itself might no longer be valid. If you think something in an old topic is still relevant, you can always link to it.
This project uses GH issues for reproducible bugs only. Everything else goes to the forum.
Where is the Joplin community's preferred place for linking to an old topic as you suggest above? For example, today I'd like to endorse a feature request for "recent notes" - this request has already been made at https://discourse.joplinapp.org/t/feature-request-recent-notes-view/3759 but I can't like or reply as that thread is now locked / old.
Doing so herein is clearly not the right place. Should I create a new thread in feature requests? Or something / somewhere else?
As a new user, I've been searching first before I create a topic - and I've found several similar cases of a type of functionality being requested already multiple times due to closing of topics on Discourse. Perhaps feature request topics could have no expiration date, so that cumulative community interest could more easily be evaluated by those kind enough to contribute time and code and who have an interest in both fixing bugs and, enhancing Joplin functionality according to both community interest as well as personal interests? I hope Joplin's generous coders take this as a positive comment / feedback.
Feature requests that have a chance to be implemented some day usually make their way to GitHub, where you can add a thumb up on the top post. We can then sort by thumb up to view the most popular.
Here we auto-close topics because to be honest there's rarely anything new added to these feature requests besides "+1" or very long posts to explain how important that feature is to a particular user, but none of this has any impact.
What would have an impact are things like:
Writing a detailed spec based on existing user feedback, which we can perhaps add to GitHub
A good example of what Laurent is talking about is @ken1kob per-notebook sorting feature. There are loads of feature requests for something like this and +1s in the forum but when this post was created with a bunch of community feedback and enguagement which led to this pull request.
There are also improvements pending in relation to the Joplin theming which has been strongly prompted by the well explained and informative posts in this thread about Joplin theming ideas.
Both of these are obviously a far cry from single text posts that simply ask for a single feature to be added which there are obviously thousands - some of them end up being simply variations on a single theme.
I do understand the frustration of not having a single obvious place to "upvote" particular features - a while ago I made a post (which ended up having no real attention - cue tiny violin) about a similar discussion - Feature requests by popularity
Since I made that post I have come to understand Joplin as a whole a lot better, not to mention the way that the community and development on the application works so I no longer fully stand behind what I was questioning in that topic.
One potential idea would be to add a new feature request area that could be manually vetted or added to only by certain users to check for duplicates, popularity and/or the quality of the request. i.e. a full post explaining what feature is desired, why it is desired, who it impacts, what workflows it could assist, similar features in other applications/services etc., how it could potentially be implemented (screen mockups, locally developed proof of concept etc.).
One benefit of that is that it could produce a list of potential features to be picked up by people who want to contribute (including GSoC) - similar to the 'good first issue' tag on github as well as being an easy place for people to look when they think they have had an original idea for a feature without just dredging up a 3 year old topic that is no longer necessarily relevant.
Potential downsides however are quite numerous:
If unmoderated then it will quickly turn into a swamp of "good original ideas" that are all duplicates of eachother with different names
If moderated then it will need active volunteers - unless the Joplin team itself is willing to perform the duties entirely
If it exists it might set an expectation that it is part of the roadmap and that it is now "official" that it will be included in a future version
Topics could end up getting artificially inflated as flavour of the month rather than the more natural inclusion where if people bring it up frequently enough then it should be considered more.
and the more likes it gets the more people want a feature. This is usually how this works.