TriliumNext / Notes

Build your personal knowledge base with TriliumNext Notes
https://triliumnext.github.io/Docs/
GNU Affero General Public License v3.0
1.04k stars 59 forks source link

(Feature request) Prevent options note title changes #556

Open meichthys opened 2 weeks ago

meichthys commented 2 weeks ago

Describe feature

Currently the title of the options notes can be changed: image

For consistency sake, we should probably not allow the options note titles to be changed.

Additional Information

No response

eliandoran commented 2 weeks ago

Yes, I've always found it weird.

The problem is a bit more nuanced, in the sense that we probably need to block a whole lot of changes to options, including moving them around, changing their icon, hiding the ribbon and so on.

Honestly, I would have fallen back to the original implementation where the settings were a modal and not special note types that reside in the user's database.

@perfectra1n , I think you have a similar position to mine.

perfectra1n commented 2 weeks ago

Yeah, I always thought it was weird to have a "settings" page that wasn't a modal. I remember when he first implemented the change, I was confused for a solid few minutes 🤣

perfectra1n commented 2 weeks ago

I'm 100% for the modal of all things settings related - we can definitely make it look good too :)

eliandoran commented 2 weeks ago

I've had a similar feedback about not understanding exactly how to exit from settings. Because it's not immediately apparent to a new user that the settings are opening in their own tab, rather than replacing the existing one.

Similarly, one of the key reasons I've mode from KeeWeb to a more traditional password manager were the settings screen that would replace the password list, and making my brain confused since it seemed exactly the same as the normal screen.

I might give it a go at turning it back into a modal. @meichthys , what's your take on this?

meichthys commented 2 weeks ago

I thought that having the options resemble the functionality of a note was interesting, but also a bit unexpected as a user. I wouldn't be opposed to switching back to a modal - especially if it is made to "look good" (hint: @perfectra1n 😜)

SiriusXT commented 1 week ago

I also think making Options function similarly to Notes is interesting, as it opens in a tab, making it convenient to switch between Notes and Options.

We could also implement a widget to prevent editing of titles and similar content, add an ESC key shortcut to exit, and other features to make it more consistent with modal operation habits.

perfectra1n commented 1 week ago

I certainly won't be in charge of making it look good 🤣

eliandoran commented 1 week ago

@SiriusXT , a hybrid might work, a single note that contains a settings widget which also has built-in navigation. The only problem with that is that I'm not sure what would be displayed in the note tree, since right now we are hoisting a hidden subtree, which is one of the main causes for confusion.

@perfectra1n , @meichthys , @SiriusXT ,

I believe we should look into how other applications handle this. I think Obsidian uses a modal. The only one I am aware of that uses this tabbed design is Visual Studio Code. There the settings open in a new tab (same us), with tree being unaffected. Clicking on a note/file in tree causes it to be opened in a new tab, with the settings remaining open.

I think this might be a good common ground since we reduce some of the complexity of the user, while still maintaining the benefits of having settings in a dedicated tab.

meichthys commented 1 week ago

This sounds like a reasonable middle ground for me. Generally i prefer modals to be ephemeral (i.e. easy to close out by clicking outside of the modal). This is great for quick notices, for shortcuts, recent notes, and others, but for settings that may require the user to press a 'save' button, I think those would better be addressed with a more 'fixed' page. Also trying to use a modal may be a bit weird since some of our existing settings have buttons that display models themselves, so you would have modals on top of modals unless further changes are made.