Potential Codebase Overhaul

[mtdvlpr]

Dear @sircharlo, as you know, I've been busy refactoring the M3 codebase to make it more maintainable, readable and modular. This is going well, but it will never have a great structure. The application is too big to create a structured codebase using vanilla JavaScript. That's why I have a proposal that I want to run by you first. I am experienced in working with Nuxt.js. It is a JavaScript framework built on the Vue.js Javascript framework. It makes life a lot easier by configuring a lot itself and creating a code structure for you. I have been able to combine this with Electron.js. The proposal is to migrate M3 entirely to a new codebase using Nuxt.JS for the user interface. I could understand that this is a big step and might be difficult for you, because you'll have to learn an entirely new framework (although it is relatively easy if you have a good grasp of JavaScript).

Benefits:

• Uses Web Development best practices
• Reusable UI components
• Structured codebase
• Easier maintained
• Faster development

Potential drawbacks:

• Learning a new framework
• Unknown compatibility issues between Electron.js and Nuxt.js (will be my first time using a combination of the two)
• A lot of time and effort that could be used elsewhere and might not be worth the benefits

If you want, I can create a simple prototype for you to evaluate. If you like it, I'll continue adding existing features until the migration is complete. After each feature you can evaluate it.

Let me know what you think!

[sircharlo]

In all honesty, I am torn. On the one side, I completely agree with you. The current codebase is huge and would no doubt benefit from being migrated to another framework. On the other side, I consider M³ to be relatively feature complete at this point in time, apart from the odd bugfix here and there and a few QOL improvements once in a while.

This, coupled with the fact that I have recently have had little (or no) spare time, due to being involved in various theocratic schools and projects, leads me to hesitate in taking on a whole new programming task (namely, learning a new framework).

If you were to start working on a new branch with Nuxt.js, I would have no objection per se; but to be clear, I would be essentially unable to make any significant contributions to this new branch, at least for the foreseeable future. You'd be on your own.

However, I am not at all "possessive" of this app, and would not mind if you took on this task. I believe that it would perhaps future-proof the code, app and its functionality, and perhaps even open the door to even more contributors adding some useful contributions in the future. I made this app open-source in part for that very reason: to ensure that the app could remain alive and actively developed for as long as the circumstances required it.

In short: I like the idea, but if you wish to proceed, you're on your own, for now at least.
We'd have to maintain two branches, until your refactored one could replace the original one without breaking compatibility with the existing users. We'd also have to maintain feature parity, in the off chance that a feature gets added or modified to the original branch during the time that you are refactoring the codebase.

That's my two cents. Let me know what you think.

[mtdvlpr]

Understandable. I will probably work on it whenever I feel like it (not too often) and when I have a basic prototype (getting media from jw.org and presenting it) I'll let you know.

[mtdvlpr]

On another note, I am still eagerly awaiting the new release with the Linux fixes and other nice changes/features :)

[mtdvlpr]

Hey @sircharlo, I'm busy with the prototype and I got stuck on something. The /languages call to get the available JW languages. I can't get it to work, I can' get the working call to show up in the network tab of the local m3 either. I keep getting a 403 error saying:
You don't have permission to access "http://www.jw.org/en/languages/" on this server.

Did you encounter this before? If not, I'll continue looking for an answer myself.

[mtdvlpr]

I am using the http adapter.

[sircharlo]

I was encountering that issue when using vanilla Axios, without the http adapter. Are you sure that the adapter is correctly configured? Also, https instead of http for the site address.

[mtdvlpr]

That was indeed the problem. Apparently axios blocks the use of the http adapter in the browser, so he used the xhrAdapter. Moving the call to the main electron process and using ipc fixed it.

[mtdvlpr]

Hi @sircharlo , I'm excited to share with you that I have a working prototype for you to test and review! It's still missing some nice-to-have features, like cong server and obs integration, but the core application stands. Would you like me to push it to a branch here or to a branch on my forked repo?

[mtdvlpr]

Good to know: the dev (local) version uses a different userData path than the production (packaged) version. This way you won't accidentally touch your own configuration when testing.

PROGRESS.md lists somes todos, dones, bugs and new features.

Src/renderer/README.md has some basic explanation for the renderer architecture.

[mtdvlpr]

And CONTRIBUTING.md explains all the different development tools used and needed.

[sircharlo]

Hey there! 👋
That's great news! Maybe for now, a branch on your fork would be best, since we're not ready to "squash" the OG version with your new version anytime soon?
What do you think?
Looking forward to taking it for a spin as soon as I get some time 😄

[mtdvlpr]

Will do! It might be sooner than you think, though. Since my last update, I have added OBS and cong server support. There are only some small todos left :)

[mtdvlpr]

Here it is:

https://github.com/mtdvlpr/meeting-media-manager/tree/refactor/next

[sircharlo]

Wow you're like Speedy Gonzales! 😆
Thanks so much for what you're doing, I really appreciate it.
Question: are you building from scratch and implementing all the features as you go, or did you start from a certain point in the existing codebase and then just move stuff bit by bit?
I ask because I just wonder if minor bugfixes (like 58a5741) will get left behind, and if so what's the best way to avoid duplicating work for you?

[mtdvlpr]

I started from scratch, but made sure to use the latest code. It is currently up to date with all bug fixes and I will check regularly to make sure your changes are also implemented in this new version.

[mtdvlpr]

Because it's a branch, it will say its so many commits behind master whenever you make changes. I will merge the master branch which will result in merge conflicts because a lot of files have been replaced. So yes it's duplicating work, but it won't easily be be overlooked and it's not that much trouble.

[mtdvlpr]

[mtdvlpr]

Nevermind, I fixed it :)

[mtdvlpr]

Hi @sircharlo , did you have a chance to look at my branch yet? As of now, the only thing left to do is testing. Testing 3 screens, the artifacts and the auto updater. And you should of course test everything else as well to make sure it's not missing any small edge case features :)

[mtdvlpr]

If you want, I can give you a demo sometime. I will also keep updating the documention inside the code to make everything clearer.

[sircharlo]

Hey there! No, not yet! It's in my list of things I want to get to though.
We've just been so busy these days. Lots of ones displaced by war moving to our area!
But as soon as I can, I'll start testing 😄

[mtdvlpr]

Totally understand. Take your time. I look forward to hearing your thoughts!

[sircharlo]

Hello again!
I tried to install the VS tools to run yarn but it's not working for some reason; it's complaining about not being able to find VS 2022. I'll have to investigate a bit more.

[mtdvlpr]

Hmm, if you have node@^16.13.0 installed, it should be a matter of saying corepack enable.
Then you can run yarn set version stable to update to the latest stable version of yarn.

[mtdvlpr]

Hi @sircharlo, here I am again. I just merged your latest changes to the docs. I have 2 suggestions:

1. I have also refactored the docs quite a bit to allow for translations. It now works similarly to M³ itself with json files for each sentence. What I would suggest would be to create a orphan branch called "docs" and use that as the place to store the docs codebase. An orphan branch is a branch that is not linked to another branch, so it would not want to merge with changes from the master branch. This has several benefits:

• GH pages would only run when docs is changed
• cleans up master branch
• makes GH langugae stats more accurate by excluding docs.

We could already implement the refactored docs in that branch (after you've confirmed that it works as intended of course). To see the changes that were made to the docs see PROGRESS.md. To see the new docs in action visit mtdvlpr.github.io/meeting-media-manager

3. This refactor seems like a good moment to migrate to obs-websocket v5. Unless you have a reason to stick with v4? If not, I will refactor my current code to use obs-websocket-js v5.

Let me know what you think!

[sircharlo]

Nothing but good ideas here! I like it. I'll test out your docs implementation in a bit.

[sircharlo]

After some tinkering, I figured out how to support both v4 and v5 for obs-websocket!

Awesome! Man I wish yarn would install dependencies properly lol. Maybe I'll try through WSL2.

[mtdvlpr]

Nothing but good ideas here! I like it. I'll test out your docs implementation in a bit.

Alright, once you're ready to adopt the new docs. Run git checkout --orphan docs to create a new orphan branch named docs. Then commit something, like an empty README md and run git push -u origin HEAD to push the branch to the remote with the same branch name (docs). Once that's done, I can make a pull request to it and you can accept. If you then set the gh-pages branch to docs in the repo settings, it will begin generating the new docs site.

[mtdvlpr]

After some tinkering, I figured out how to support both v4 and v5 for obs-websocket!

Awesome! Man I wish yarn would install dependencies properly lol. Maybe I'll try through WSL2.

Did you update yarn to version 3? yarn set version stable. By default version 1 is shipped with node.js@^16.13.0.

[mtdvlpr]

@sircharlo, did this work? Also, once you make the docs branch like stated above, I'll create a pull request for it.

[mtdvlpr]

Hi @sircharlo, if you keep getting stuck setting up the dev environment it might be beneficial to have an online meeting sometime. I think there's a 5 hour time difference between us (it's 11am here at the time of writing this comment). Some days I'm available until 11pm (6pm for you?).

Let me know!