Revise settings about rnote

[silvasch]

Yeah, I think that's fair. Tomorrow I'll focus on implementing the right-click menu, and then I'll try to move the document layout and developer options to the preferences.

[flxzt]

The main reason I implemented it as a sidebar is because I want to give users a live preview when document settings are changed. If it were a (modal) window, it would be cumbersome to make changes by: changing value -> closing window -> inspect change -> possibly reopen window to adjust and so on

Edit: regarding splitting up the shortcuts section into its own page, that sounds like a good idea - it grew a lot over time, initially there were only three shortcuts. Not sure how it should be named though, so it's not confused with the global app shortcuts window. Maybe "action shortcuts" or "canvas shortcuts"?

[silvasch]

The main reason I implemented it as a sidebar is because I want to give users a live preview when document settings are changed.

That makes sense. So maybe the settings could be split into two parts: The "Page format" and "Document" settings stay in the sidebar, and the tab would be called "Canvas settings". All other settings don't require a live preview and could be in the new, separate window called "Preferences".

I was also thinking about moving some settings from the "Canvas Menu". The "Document Layout" option could be moved to the sidebar, together with the "Show Format Border" and "Show Origin Indicator" settings. The "Snap positions", "Draw with Touch Input" and the "Block pinch to zoom" could be moved to the new preferences window. I always found it confusing why these options are in a separate menu, when they could fit perfectly into the rest of the settings.

[flxzt]

Hm, I am sceptical about splitting the settings themselves in two parts. It might be unclear to users where to find what. I currently don't see the benefit of a dedicated preferences window.

The "Document Layout" option could be moved to the sidebar

Agreed, that could move into the document section.

The reason why some of the options are in the canvas menu is that they are frequently accessed and frequently changed, making them more easily accessible.

[silvasch]

Now I'm not sure what you meant by "splitting up the shorcuts section into it's own page". Do you mean adding a tab next to "Workspace" and "Settings" in the sidebar?

[flxzt]

Yes, similar as you outlined but instead of inside a AdwPreferencesWindow as an additional AdwViewStackPage in the AdwViewStack which is the container for the sidebar pages.
At least that's what I think would make sense, unless you have other suggestions?

[silvasch]

If you don't want to add a separate preferences page, that would probably be the best option.

What do you think about moving some other options from the menues to the settings page?
Options like color scheme, the developer options, the document layout and the sidebar position aren't used often and could be moved to the settings.

Btw, this is unrelated, but what does the "Pen Sounds" option do?

[flxzt]

I agree with moving the document-layout to the settings.

Unsure about some of the items in the app-menu, especially the sidebar position buttons can stay IMO.

Regarding moving the developer menu into the settings - I am not completely opposed but it would need discussion - how would you port it to list rows? The export-engine and export-state actions mirror the actions of the "regular" export options in a submenu nicely - implementing them as actionrows containing a button that activates these actions could feel weird.

[silvasch]

how would you port it to list rows? implementing them as actionrows containing a button that activates these actions could feel weird.

I would implement them as actionrows, just like the Invert color brightness button. To me this doesn't feel weird.

Unsure about some of the items in the app-menu, especially the sidebar position buttons can stay IMO.

My primary goal with this PR is to make the places where you can find all these options to a consistent place. I think the app menu has to many options that could all be moved to a better place. I feel like the sidebar location buttons should move to the settings because I don't think they're often used - you change the setting once and then it stays there (unless you want to move the sidebar all the time, but I don't see why.)

[flxzt]

Just to play devil's advocate here:
I'd argue that the Invert background brightness action doesn't fit very well in the settings either - it's not something that can be configured, it's only something that gets executed.

[flxzt]

Lets go through it item by item.

• Sidebar position buttons: okay, I can see how that is not changed that often. However there is predecent to have such controls in the app-menu in other apps. I don't have the data to back it up right now but I think most users would first look there instead of the preferences. If you look further outside Gnome apps you'll find the same thing - for example thunderbird also has it's sidebar/layout settings in the menu. Also: where would the maximize button then go? It definitely does not fit into the canvas-menu and is also commonly found in the app-menu in other apps. The print item could be moved next to it as a button - but that would also be less than ideal because printing lacks export options - that is not yet implemented and I don't want to have it positioned very prominently because of that.
• color-scheme toggle. Same goes there: It is almost always found in the app-menu. Only builder has duplicated controls for the color-scheme in its settings. The reason it is not implemented as bright/dark buttons as seen in other apps like builder, apostrophe, text-editor etc. is because the color-scheme does not change the document background color. A libadwaita dev suggested to make it less prominent by adding a submenu for it.
• document-layout: yes, as mentioned that can be moved
• the developer settings: okay, I guess it could be an expander-row which reveals the developer-menu. However, only visual-debug option can be considered a "preference". I expect that more actions will get added to the dev-menu over time, not more configurations.

Additionally, there is already a factor of familiarity that users learnt over time - if we suddenly change around UI elements, I expect that it will create friction - it happened when I introduced the toolbar overlays, ported the app layout to libadwaita 1.4 and it's new adaptivity widgets, .. .

This is the reason I am conservative about UI changes. If you give me good reasons and have thought it through to the end, I can be convinced. A design image created with something like figma oder penpot or even a mockup implementation would help with that. But otherwise I don't see the point of it - it feels like moving things around for it's own sake ("auf der stelle treten" if you will) and I'd rather spend the time discussing new features, I am a lot happier doing that