[Discussion] Towards better settings (and per-channel settings)

Lots of issues, PRs, discussions and disagreements have an impact on settings. In this fork alone, I can mention https://github.com/thelounge/lounge/pull/57, https://github.com/thelounge/lounge/pull/70, https://github.com/thelounge/lounge/pull/28, https://github.com/thelounge/lounge/pull/49, https://github.com/thelounge/lounge/issues/80, https://github.com/thelounge/lounge/issues/44, https://github.com/thelounge/lounge/pull/70, … and we are only 2-week old!

This is only going to get worse as we improve theme management (or create theme management for that matter) and add packages, who will have their own settings, potentially affect existing settings, …

Before we start adding dozens of settings to the current setting page, we need to discuss the long-term goals.

I have been building a mockup of the settings page slightly revisited. I propose we discuss its style, content, interactions, underlying structure, usability, … (but the CSS/HTML is gross, this is just a mockup 😛) I will update the mockups as the discussion evolves.

One very important aspect is to keep user-friendliness as we evolve, or we will end up being a cluttered application as most IRC clients are. Defaults should be sensitively chosen to enhance the experience of any new user (of The Lounge or IRC altogether). Considering a private instance of The Lounge can be maintained by one administrator and used by many users, it’s not crazy to think The Lounge may be used to introduce new folks to the IRC world 😃 Also, not everything should be a setting (“Better settings” does not mean “more and more settings” :p). Any UI-specific choice should ideally be the responsibility of a theme author, and may be overridden using custom styling. However, advanced and very advanced users should be able to find happiness here too. When it comes to styling, a custom style field should give them the ability to make changes to a very fine-grained extent. We might want to be able to do the same thing for the settings overall: if all interactive elements for settings (checkbox, inputs, …) match to an underlying data structure, some settings might be so advanced that they should be edited in a text field directly (like the custom styling, but for settings themselves). This might be an impractical idea after discussion, but focusing on keeping the UI slick and simple is key here.

Also, everything that appears on the settings page, apart from the profile section obviously, is device-specific. Therefore, everything should be stored in the localStorage and not be synced with the server. We could argue that some settings should be synced on the server and some should not, but that would lead to confusing settings and very difficult specificities to handle. I propose we start like this and improve with server sync later. Doing the other way around would prevent users to have different settings on different clients altogether, while this way allows for more freedom.

As packages will arise, they will come with their own settings. Packages should not mess with other packages’ settings, so we might want to namespace/prefix them. For example:

general:
  showMode: true
  ...
emoticons:
  enabled: true
  ...

As core features move to separate (but officially supported / part of the GitHub org) packages, they need to fallback to their old name (example: general.notificationsEnabled -> notifications.enabled) to not affect existing users. We need to decide if we want to allow packages to have their settings entries spread across the settings tabs or under a Settings button for each package.

That’s all I got for now. It’s rather long already, but praise my stupidity for having lost all my notes right before opening this issue! I hope that you’ll like my mockups and that we can peacefully discuss to reach consensus 😃

Example

[igalic]

Per channel highlights

Feature Description

I’m in a number of tech related channels, in some of those, i would like to follow a specific subject. However, while adding freebsd as a global highlight would enable me to follow new developments i’m interested in in #cloud-init, it would make #bsdports unusable.

I would like to be able to set per-channel highlights.

[AlMcKinlay]

Alright, that wasn’t clear.

But generally, unless someone mentions it, it isn’t being worked on. We’ll hopefully get to channel/network settings sometime, but it’s not the highest priority. We are always open to PRs if people want to write the code themselves.

It might be easier once #2636 is done as well, although we still need to sort out the server-side part of settings before that.