Configure per action desktop/mobile about customizable-page-header-buttons

[kometenstaub]

Thanks!

That would be possible, but I‘m opposed to implementing it directly in the buttons chooser for two reasons:

1. I don‘t use it on desktop, I only added support for it on request (see #6), and I don‘t want to maintain additional complexity that I’m not using.
2. I hook into the file-open event which gets fired each time a new pane gets opened, the file in the current pane changes or a different pane gets clicked. Then I check for every button whether it‘s there. I don‘t really want to make it more complex and check more conditions. The performance might not be that important with only this plugin, but the more plugins start hooking into events, it might lead to lags in the future. I‘m not exactly sure of performance implications, but I‘d like to keep it as lean as possible. I used to check whether a pane was already opened (the ID stays the same for each pane) by keeping track of the ID in a set, but that proved to be unreliable as soon as non-markdown panes were involved.

If you look at the DOM, you can see that there are multiple buttons, depending on the pane, that are hidden with display: none. I give the buttons distinct classes based on their command ID, so you should be able to hide them with a snippet.

Example:

.is-desktop .view-action .switcher:open {
    display: none;
}

I didn‘t check that selector yet and I‘ll also add one more class to make removing the buttons onunload independent of the settings by request of Licat. You can add such a snippet already and the class I‘m adding shouldn‘t break the snippets, but I would wait until I have released the new version.

What I could imagine to do is adding a new setting to automatically add such css rules based on a dropdown menu to either do nothing/hide on desktop/hide on mobile, if the setting to enable them on desktop is enabled. That also makes it less complex for users who only want to use it on mobile.

That being said, I don‘t know whether it is more resource-intensive to apply the CSS or check extra conditions. Considering that Obsidian adds these buttons anyway and hides them with display: none, I think it is better to do that with CSS.

What do you think?

[kometenstaub]

Although the extra checks would only happen for new panes.. Hmm..

In any case, I don't want another suggester for selecting it, I want to keep the initial configuration as simple as possible.

Also, if I don't add this before approval, then it could be a breaking change to many users, depending on how I design it.

The CSS option I could always add at a later point without breaking people's workflow.

[TfTHacker]

You can make changes while waiting approval, just make sure the current "Release" is stable. I can't say what the best implementation is, but it will be useful.

I do always say though, build what you use. Nothing works better than when you work with it yourself for shaking the features down.

Thanks for considering this request.

[kometenstaub]

I've looked at the DOM now, there is no .is-desktop class. There is .is-mobile. So my CSS approach wouldn't work.

[kometenstaub]

You can make changes while waiting approval, just make sure the current "Release" is stable.

Yes, what I meant is that I'd need to decide now how to implement it because I don't want to introduce breaking changes once it's approved.

[kometenstaub]

I'll think about it, there might be a simple way after all.