search

vc4all / jitsi-hacks

Changes in Jitsi to make it more suitable for our needs
1 stars 0 forks source link

Warn when using Firefox #6

Open berkes opened 4 years ago

berkes commented 4 years ago

As a participant in a group chat, when one of my peers is using firefox, I want that person to be warned that our group-experience becomes sub-par, so that people can move to better supported browsers.

afbeelding

BjornW commented 4 years ago

FYI: According to this statement on Jitsi's forum they expect to have a better experience for Firefox very soon.

BjornW commented 4 years ago

screenshot-2020-04-10_16-02-57 Removed firefox from OPTIMAL_BROWSERS: [ 'chrome', 'chromium', 'nwjs', 'electron' ] in interface_config.js. This will display a warning when using Firefox. Seems this is not yet translated as the message was in English.

berkes commented 4 years ago

Did you push a new build for this, or how did you get this fixed?

We should try not to change files on the server without either incorporating them in ansible, or in our fork of jitsi-meet that we can deploy ourselves (see https://github.com/vc4all/ansible/issues/17).

This will break and when it does, there is no trace why it broke, when it did and so on.

Can we manage the interface_config.js with ansible? AFAIK settings in that file are (partly) used when building the project. If settings are picked up without rebuilding&deploying jitisi-meet, we could circumvent https://github.com/vc4all/ansible/issues/17 and instead implement a simpler approach that mimics how we now manage config.js in ansible.

BjornW commented 4 years ago

Did you push a new build for this, or how did you get this fixed?

Changed the /usr/share/jitsi-meet/interface_config.js file on the server itself. IMHO this file should have been placed in /etc/jitsi-meet/ as it is a runtime config file. Might file an issue about this upstream.

We should try not to change files on the server without either incorporating them in ansible, or in our fork of jitsi-meet that we can deploy ourselves (see vc4all/ansible#17).

I Agree, I'd prefer this to become part of our playbook as well. Since this is a config change in interface_config.js I don't think we need to make a build just for changing these type of changes.

Can we manage the interface_config.js with ansible? AFAIK settings in that file are (partly) used when building the project.

Are you sure it is used in building as well? I got the impression this is a runtime config file and not used during build, but I haven't looked into the building process yet.

If settings are picked up without rebuilding&deploying jitisi-meet, we could circumvent vc4all/ansible#17 and instead implement a simpler approach that mimics how we now manage config.js in ansible.

Yes, as far as I can tell most of our changes so far can be done at runtime: translation can be replaced, watermark can be replaced and settings can be set in both config.js and interface_config.js at runtime. Am I missing something?

berkes commented 4 years ago

Yes, as far as I can tell most of our changes so far can be done at runtime: translation can be replaced, watermark can be replaced and settings can be set in both config.js and interface_config.js at runtime. Am I missing something?

In that case we can use the same approach as config.js. It probably needs to go upstream to cimnine.jitsi-meet role, so the best approach is to branch off and hack it there. The role directory is a git repo in itself (not a submodule) so that works fine AFAIK.