Please keep settings grouped logically

[dandv]

Is your feature request related to a problem you are facing?
I'm new to Jitsi and trying to figure out the various settings in its various config files. I've read the Handbook, but haven't found a page that explains the settings, so I have to rely on the comments in interface_config.js and config.js. (If there are other config files, I don't know yet, because, again, they aren't clearly explained in the Handbook - jitsi/handbook#61).

The problem is that all settings in interface_config.js were recently sorted in alphabetical order. Before, these settings were grouped logically. For example, if we wanted to configure branding and watermarks, the settings were in one place (and other related settings could be brought to the group):

    // if watermark is disabled by default, it can be shown only for guests
    SHOW_WATERMARK_FOR_GUESTS: true,
    SHOW_BRAND_WATERMARK: false,
    BRAND_WATERMARK_LINK: '',

Now, watermark and branding settings are spread apart, and other settings come between them:

    AUTO_PIN_LATEST_SCREEN_SHARE: 'remote-only',
    BRAND_WATERMARK_LINK: '',  // <-- watermark and branding setting

    CLOSE_PAGE_GUEST_HINT: false,

   ... lots of other settings unrelated to watermarks and branding ...

    SHOW_BRAND_WATERMARK: false,

    /**
    * Decides whether the chrome extension banner should be rendered on the landing page and during the meeting.
    * If this is set to false, the banner will not be rendered at all. If set to true, the check for extension(s)
    * being already installed is done before rendering.
    */
    SHOW_CHROME_EXTENSION_BANNER: false,

    SHOW_DEEP_LINKING_IMAGE: false,
    SHOW_JITSI_WATERMARK: true,  // // <-- watermark and branding setting
    SHOW_POWERED_BY: false,
    SHOW_PROMOTIONAL_CLOSE_PAGE: false,
    SHOW_WATERMARK_FOR_GUESTS: true, // <-- watermark and branding setting

This separation makes it even harder to figure out what the settings do and how they relate.

The only argument I've seen for sorting this file is that it makes it easier to compare it across different deployments. I think that's,

1. A far less common use case than users with a single file
2. A use case for experienced sysadmins, who

• know what the settings do
• can use a decent diff tool
• or pipe the files through sort before comparing them.

Given the current situation, Jitsi has a large influx of new users.

I don't think confusing most new users by sorting settings alphabetically, outweighs the minor benefit for occasionally comparing the file across multiple deployments, which can be solved by piping them through sort.

Describe the solution you'd like
Revert the commit that sorted the settings in interface_config.js, and apply subsequent commits that did materially improve the file (e.g. #7169, #7170, #7172).

The settings in config.js are also grouped logically, and that's very helpful. Why not preserve that convention?

[saghul]

I agree. We are about to deprecate interface_config.js and will be moving to a unified and semantically sorted config.js. The effort is bound to start soon, but it will take some time, since we do have backwards compatibility requirements.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.