Consider using React for V2

[murfett-au]

I’ve just started using DCC++ and (for work) I write React Java script code. I think it would make development of DCC++ much easier, but only if the key people know what it is and would consider using it.

I would be happy to knock up a prototype.

[FrightRisk]

Looking for Mani, Matt, and Jeff to join and have a planning discussion about a new development platform, what needs to be rewritten, and which new feature to begin with for the next version. - Fred

[FrightRisk]

We had an ongoing discussion in issue 57. Should we continue it here or just add to that and make future discussions here? #57 (comment)

[ManiAkasapu]

I would leave the decision to experts. I saw discussions at #57. I will be acting as UI designer for this project for now.

[FrightRisk]

Are you still with us @murfett-au ? I think we are ready to go with React

[hansSchall]

There are a few decisions we have to make before we start writing:

1. Do we use ES6 imports?
2. Do we use React as a global variable or imported?
3. Do we use Webpack?
4. Do we use function or class react components? My choice would be function components.
5. Which browsers do we want to support? Only Chromium based? Firefox, too? Mobile versions?
6. Do we create an entirely new repository (complete rewrite)?
7. What about the suggestion of adding an optional Node.js "gateway" server? => multiple clients, more hardware abstraction, maybe support for connecting via network instead of serial/USB, mobile support
8. Do we use any CSS preprocessor or framework? I would suggest SCSS as it simplyfies resusing code and :hover effects.

[hansSchall]

Does anyone have experience with these things? Should I create a template (index.html, index.ts, tsconfig.json, webpack.config.js, package.json, react includes, ...) after we have decided all the questions above or does something like this already exists? If yes, where?

[matt-vdv]

I know nothing about react so I can't comment on that front but I can strongly recommend typescript.

As far as CSS goes I've found tailwind CSS to be really good for this sort of thing.

As for browser support/backend, making the backend (connection method) modular seems like a good idea to me as it future proofs as such. If we want to use the serial usb for now then it will be chromium based browsers.

Also whatever is chosen will need to be able to be built to a static page with no backend to allow hosting on GitHub pages, or we could get people to download and host themselves?

And finally I'd suggest a new GitHub repo. I think we should try and set up some automated tests with GitHub actions, then restrict direct pushes to main. This would mean all code merged into main would have the tests run on it first.

[hansSchall]

All together there will be 3 options to run the app:

1. as a website (optional to install as PWA), works only in chromium-based environments (WebSerial)
2. as a local hosted website, works only in chromium-based environments (WebSerial)
3. Node.js server, delivering the main app statically and a WebSocket connection to access the SerialPort connected to the computer running the server, works in all modern browsers.

I would suggest splitting the app in 3 parts:

• Client: UI, WebSerial bindigs
• Server: Node.js, node-serialport bindings; optional
• CommandCore: maintains global state (loco speed, dir, fn, powerstate); translates everything to DCC++ commands ¹ and parses the incomming; if WebSerial is used, this is executed in the client application, if Node.js server is used, it will be executed there; needs two tsconfig.json (one for web build (es6 imports), one for the node.js build (commonjs/require imports)

About tailwind CSS:
As far as I see, this uses it's own build tool, which seems to be incompatible with React or Vue. They both use JSX/TSX which looks like HTML, but it is more JS/TS.

I think SCSS is better:
It is not a CSS framework and it doesn't provide any style, it just simplyfies devlopment.
You don't need any configuration files. The compiler can be installed as an extension in VSC.
It is like TypeScript: all valid CSS is also valid SCSS, but you can use additional features:

// you can use JS-like comments
// SCSS:
.foo{
  display: flex;
  background-color: red;
  ...
  &:hover{
    background-color: blue;
  }
}

//CSS:
.foo{
  display: flex;
  background-color: red;
  ...
}
.foo:hover{
  background-color: blue;
}

// this is much clearer if you use :hover, :focus, @media-queries

// additionally you can use:
// - mixins
// - variables

// note: there is another lang called SASS, which is very simmilar and they share the compiler base, but is (in my opinion) harder to read, because the {} and ; are missing

// see: https://sass-lang.com/guide

All the build tools I suggested have a feature watch-mode: The compilation process is done while you switch the window to view the result. Under normal conditions you don't notice them.

@ALL: please tell us your opinion about all these things.

@ALL: I have much free time now, should I create a basic setup (in my personal GitHub profile) using React, TypeScript, SCSS (can be removed later, other CSS libaries like Bootstrap, W3CSS, or a full build (without compiler) of tailwind), two-target compilation of the DCC++ command ¹ generation, and so on? For my own little testing applictation I have alredy written a DCC++ command ¹ parser and basic bindings.

Footnotes

1. How to call these commands: DCC++ commands? EX-DCC commands? CommandStation commands [sounds strange]? ↩ ↩² ↩³

[FrightRisk]

@hansSchall It amazes me how very, very specific tools are for programming. It is very much like spoken language. You can be fluent in English and not have the slightest notion of what someone is saying in German. We do not have anyone currently who knows much about WEB development. I know C++, C#, VB.NET, and Delphi. I have no clue what you are talking about. I obviously understand the concept of libraries, and understand React is simply a library, but would have to understand my choices to know the best course.

I have a web developer who knows a bit about these tools who also helps with the installer. We have @matt-hu who should have a decent understanding, @murfett-au suggested React so if he is still willing to help, I would encourage input from him. @ManiAkasapu is great with visuals and user interface. If we can build a team around that, then we should start.

The history of the project began with me. I cobbled together a concept using HTML and JavaScript. Mani made it look pretty and added a lot to the code. Matt came in and restructured the code and that pretty much is what you see today. We have no trouble on Discord with the development team for EX-CommandStation, but have not been able to create a self-sustaining team for the installer or the web throttle.

I am hoping we can get at least 3 other people talking about this, but in the meantime, you are going to have to explain what each thing you mentioned does or I am going to have to spend a few days learning each thing to be able to talk about it.

Fred

[dexslab]

All together there will be 3 options to run the app:

1. as a website (optional to install as PWA), works only in chromium-based environments (WebSerial)
2. as a local hosted website, works only in chromium-based environments (WebSerial)
3. Node.js server, delivering the main app statically and a WebSocket connection to access the SerialPort connected to the computer running the server, works in all modern browsers.

I would suggest splitting the app in 3 parts:

• Client: UI, WebSerial bindigs
• Server: Node.js, node-serialport bindings; optional
• CommandCore: maintains global state (loco speed, dir, fn, powerstate); translates everything to DCC++ commands ¹ and parses the incomming; if WebSerial is used, this is executed in the client application, if Node.js server is used, it will be executed there; needs two tsconfig.json (one for web build (es6 imports), one for the node.js build (commonjs/require imports)

About tailwind CSS:
As far as I see, this uses it's own build tool, which seems to be incompatible with React or Vue. They both use JSX/TSX which looks like HTML, but it is more JS/TS.

I think SCSS is better:
It is not a CSS framework and it doesn't provide any style, it just simplyfies devlopment.
You don't need any configuration files. The compiler can be installed as an extension in VSC.
It is like TypeScript: all valid CSS is also valid SCSS, but you can use additional features:

// you can use JS-like comments
// SCSS:
.foo{
  display: flex;
  background-color: red;
  ...
  &:hover{
    background-color: blue;
  }
}

//CSS:
.foo{
  display: flex;
  background-color: red;
  ...
}
.foo:hover{
  background-color: blue;
}

// this is much clearer if you use :hover, :focus, @media-queries

// additionally you can use:
// - mixins
// - variables

// note: there is another lang called SASS, which is very simmilar and they share the compiler base, but is (in my opinion) harder to read, because the {} and ; are missing

// see: https://sass-lang.com/guide

All the build tools I suggested have a feature watch-mode: The compilation process is done while you switch the window to view the result. Under normal conditions you don't notice them.

@ALL: please tell us your opinion about all these things.

@ALL: I have much free time now, should I create a basic setup (in my personal GitHub profile) using React, TypeScript, SCSS (can be removed later, other CSS libaries like Bootstrap, W3CSS, or a full build (without compiler) of tailwind), two-target compilation of the DCC++ command ¹ generation, and so on? For my own little testing applictation I have alredy written a DCC++ command ¹ parser and basic bindings.

Tailwind works just fine with Vue but we would have to make the components by hand which isn't difficult. as for using scss or sass that I fully support as it makes using css variables a lot easier. I love the idea of the break down into different components I just recommend we do a PWA using Vue3 as the framework since it's a lot easier to read and understand compared to react

Footnotes

1. How to call these commands: DCC++ commands? EX-DCC commands? CommandStation commands [sounds strange]? ↩ ↩² ↩³

[FrightRisk]

Let me start with what we need, which may dictate the tools used. Here is what makes EX-WebThrottle (we are standardizing to EX as the prefix for everything):

1. It needs to be simple and intuitive
2. It should be able to replace the Arduino IDE for debugging as a serial monitor, and hopefully, become an installer
3. It is the simplest "getting started" throttle. Everyone has a computer or a phone and could either download the files or run them and test their CS as soon as they put it together. JMRI is ridiculous unless someone has used it for a while, phone throttles require installation, are phone specific, etc.
4. Now you need Chromium and a USB cable or a phone with an OTG cable, but other browsers or Bluetooth/WiFi, would be nice.
5. It needs to be "pretty". We have 2 themes now, and they are a good start. We have DCC-EX colors to use.
6. It needs to be self-contained. Much like the nightmare IMHO "mistake" of the Windows registry, everything should be able to run from things just unzipped to a folder. A user should be able to open a browser, click on a link or an HTML file and it runs. It would be nice if they don't have to install anything.
7. The development process needs to also be simple and not require a lot of steps, downloading, etc. We can't even get consistent effort now, the more complicated it gets, the fewer coders we will be able to find with expertise, let alone interest.

Maybe the first option to decide is the node.js server. What is involved for A. Us and B. The user? It is a "server" running on the user's machine? It doesn't have to run on a server we maintain? Or does it? Would there be anything the user would have to install or deal with in some way? We need this to be for Conductors, they should only have to learn the throttle controls, not have to worry about dependencies versions of other things they have to have on their computer.

Fred

[FrightRisk]

1. We can save the current released version of WebThrottle, what benefit do you see of needing a new repo?
2. If we use all these tools, we would need a document that anyone could pick up and be able to develop. Can you outline the steps now? What has to be installed? When developing, how complicated is the build process? Now, there is no build. You write JavaScript, CSS, or HTML and it is ready to go.

I understand the price to pay for using modern tool is a build. The CS needs to be compiled and built, as does the web page. But how easy is it? I do love the tools in the browser to be able to actually debug things with React.

[hansSchall]

1. It's a entirely new codebase; dealing with different versions, branches (we would have 2 main branches), issues and PRs on different targets doesn't make life easier and confuses people simply wanting to use Ex-WebThrottle. I would also name the repo dcc-ex/Ex-WebThrottle2.

2. To run the build tools you need Node.js. Run npm install -g yarn; yarn is an alternative package manager, simpler, more powerfull and most times faster than npm, but compatible. npm install -g typescript, (npm is better for global installation of tools). Now you can use tsc/tsc -w (-w watch mode) to compile the TypeScript code. The SCSS compler is just a VSC extention (called "Live sass compiler). If we use any libaries installed through npm/yarn you need to install these by running yarn install or npm install in the subfolders containing a package.json file. That's all!

You can use all the tools you like, because the TS and SCSS compilers emit SourceMaps (if enabled). These are .map files describing the corresponding TS line and column of each JS line and column. These are used by the web devTools to modify their error messages.

About compile time: If your computer is fast enough to run VSC fluently, it is fast enough to run the typescript compiler faster than you can switch to the browser window. The builtin TS language support of VSC is built on the offical TS compiler, so it emits all messages to the problems panel. You don't need to take a look at the compiler output.

[FrightRisk]

So after installing all these things, what does the development process look like? You code in VSC, then hit the build button which invokes the typescript compiler? And this puts code in a subfolder of the project folder?

And how does it work for users at runtime? Now, we just have all the files on github here: https://dcc-ex.github.io/WebThrottle-EX where all the files are just placed in a folder and it runs from there. Or, you can just copy those files locally and it works with no internet connection. What will be different with this system? Will we have to install a node.js runtime for the user? What would be the point of writing it to run in a browser if you still need something external to run it?

From one of our developers when we were talking about using websockets, which is NOT supported on the Command Station: "But to implement websockets just to support a throttle that needs that because it happens to run in a browser is why oh why?
Can't one just combine it with another library and get an app out of it?"

We don't have websockets because we code to the AT command set of the ESP devices and use their network firmware handle the connection. We also may not have the RAM in the Arduino to support writing websocket code. I don't know if the AT firmware on the ESP8266 can handle websockets. So EX-WebThrottle would have to work the same way the phone throttles work if we have a WiFi path.

[FrightRisk]

We have had several people volunteer to use Vue. I understand there are more React people than Vue people, and we want this to be maintained when people ultimately disappear never to be heard from again. But Vue seems to be growing and while I would lean towards React, there are small things that keep popping up that aren't mentioned in a lot of the comparison's I read.

One of our developers said that a disadvantage when writing react is having to do a render function and attempt to get all the code within quotes which makes formatting a tedious chore. And the code is harder to read the more complicated a site gets (which is why yet more tools are created like ionic)

@dexslab mentioned he already converted most of the project in an afternoon using Vue. To him I say, "then commit to it and show us what you've got" ;) To the rest of us, is there a reason NOT to go with Vue? According to Dex, I would still understand the code if we used Vue ;)

[alex-code]

I'd never used Vue but managed to rewrite all my WiFi throttle web UI with it.
It has good documentation and the interactive tutorial helped to learn it, https://vuejs.org/tutorial/#step-1

[FrightRisk]

So far Dex, Matt and Alex like Vue. Murfett and Hans have the React experience. I don't want to make the wrong choice, but I need to go with someone who will commit to the project, help drive it, and be available for at least 2 years to consult with if not continue development. We can't get halfway through the project, lose the key developer, and then have no one to pick things up where it was left off.

My 2 big issues are how many steps for a developer to start and build something and how many steps for a user. I have looked and see that as far as coding, it is mostly just syntax differences, but a person who knows one, will still have to learn how it is done in the other.

[dexslab]

I don't plan on going anywhere anytime soon. I may not be active 100% of the time but I am still here and still willing to work. If anyone has access to the repo you should be able to see webthrottle-vue and actually take a look at the code it's already up and you can run the project now. It's a fairly simple process to get it up and running as long as you have node JS installed.

[dexslab]

Hi I am Dex and I have started to remake the project in Vue already Vue3 specifically. The learning curve for Vue I feel is easier and better suited for anyone wanting to dip their toes into helping us. I can convert current code to composition API to help facilitate this as well.

[matt-vdv]

I'll give addressing some of this a go:

Hosting

As far as I know, both Vue and React can be compiled to a single HTML, js and CSS file. This means we can continue to host on GitHub Pages like we currently do, no installing anything for the user. Obviously with this solution theres no backend to run code on but with webserial this isn't really a problem. Also a WiThrottle client may be possible without a backend.

Node

Node would only be required for developers and is relatively easy to set up, I could write a wiki page detailing how to get started for new developers once everything is set up. In short, all that needs to be done is to install Node then run npm install to pull all the dependancies. Also, we can set up Dependabot to automatically update depenancies for us.

CSS

I can see that SCSS could be quite powerful, but I'd like to point out that tailwind definitly does work with Vue/React, see this page here:
Tailwind with Frameworks

After following this guide for vue I have it set up to generate the needed tailwind classes every time the vue reloads, as part of the vue build process.

I'm not saying it's the best solution in every situation, but I've been doing a fairly large project with Vue and Tailwind and really liked it. There is a VSCode extension which is good and I like keeping all the stying in one place. It also is easy to conditionally style elements like this:

<h1
   :class="hidden ? 'hidden' : 'block'"
>
    Some text
</h1>

Where hidden is a boolean variable in the typescript.

VSCode

VSCode works really well with typescript and vue, and I'm sure it does with React as well. When everything is decided upon I can set up a workspace that we can all open in VSCode with shared settings etc. You can also set up recommended extensions with VSCode workspaces which would help new developers join the project.

New repo

I personally think that a new repo would be best as it will allow for a fresh start. Some of the other benefits would be allowing us to continue offering the current website whilst the new one is in beta and I could add a banner to this one notifiying people of the new version. This would also allow us to rebrand easier without breaking links etc as the repo name is part of the URL to access the site.
Also if we wanted to use dependabot (see above) this would be much easier on a new repo.

React Vs Vue

I wouldn't mind if React is chosen but from what I've heard they are fairly similar. Vue is basically just combining the js, HTML and css into one file but in distinct sections. Either way both are fairly common so finding new developers shouldn't be too hard.

As for why I chose Vue instead of React to learn, it was simply just principles as I didn't like that React was made my Meta that's all!

Formatting and consistency

For the new version if we are using something node based (which looks probable) I'd quite like to introduce eslint with some formatting rules such as one quote style and hopefully we can agree on a tab size! I seem to remember this was a bit of a problem before with a mismatch of indents on different files

I realise this is quite a bit to read but hopefully this should help clear up some of the questions in this thread. If anyone still questions (or more likely new ones!) please don't hesitate to ask

[dexslab]

Also here is the link for the current project I started. Its written in Vue 3 and i started conversion of current sites UI and functionality.

WebThrottleEx-Vue

[matt-vdv]

@dexslab Just had a look at that repo and I like the decisions that have been made to use Pinia and Vue router.

The only thing I do want to say is it looks as if you have copied and pasted code from this repo. Some of the code in this repo is of pretty low quality (especially the stuff I added!) and when I attempted to copy and paste in the past it was adding the javascript in that was the hard part, due to the site being designed with JQuery in mind.

I'm not saying that copying the HTML is a bad idea! I just wonder whether a ground-up rewrite would be easier in the long run, what does everyone else think?

[dexslab]

@matt-hu So the only thing i copied was the HTML and CSS which we can easily convert to sass or scss depending on what we need to do. If you look at the vary bottom of each .vue page there is no JS logic. My goal was to get the UI and state system up and running. Along with serial stuff then work on logic. We should most likely move HTML that repeats into components and go from there. The project as it stands runs and you can move thru the pages. It is a SPA so its fairly snappy but still not truely reactive yet and there is work to be done.

[chartinger]

In terms of formatting, there is always Prettier. (Yes, i fully understand when someone says "but it's opinion is wrong" :D but it makes having consistent formatting sooo much easier). It does however not replace eslint, as eslint static code analysis function is just too good imho. (e.g. ts-specific no-floating-promises)

[matt-vdv]

In terms of formatting, there is always Prettier. (Yes, i fully understand when someone says "but it's opinion is wrong" :D but it makes having consistent formatting sooo much easier). It does however not replace eslint, as eslint static code analysis function is just too good imho. (e.g. ts-specific no-floating-promises)

Whilst I like the principle of Prettier (yes this is a "it's opinion is wrong statement") and most of it's rules I can deal with, the one thing I didn't like about it is not allowing two consecutive blank lines as I feel that this can really help with readability sometimes. Nonetheless we should still consider using it. I have in the past added some of the stuff prettier does to eslint as warnings, and that no-floating-promisies rule looks a good one, thanks for the tip!

@matt-hu So the only thing i copied was the HTML and CSS which we can easily convert to sass or scss depending on what we need to do. If you look at the vary bottom of each .vue page there is no JS logic. My goal was to get the UI and state system up and running. Along with serial stuff then work on logic. We should most likely move HTML that repeats into components and go from there. The project as it stands runs and you can move thru the pages. It is a SPA so its fairly snappy but still not truely reactive yet and there is work to be done.

That's a good point, if only the HTML and CSS are retained it's certantly a good starting point! We can gradually strip out the ids etc not needed and move things to components plus simplify/convert the css to SASS or tailwind.

[ManiAkasapu]

upon decide on the tech, Use the basic layout to start with.

[matt-vdv]

Looks good!
Will you be able to provide us with the images/icons/fonts etc when we are ready for them?

Also I think we'd like to include mobile support in case we are able to implement WiThrottle later, so that's something worth bearing in mind.

[ManiAkasapu]

Sure.

[dexslab]

If we use something like tailwind or what ever we have total control over breakpoints and mobile optimization.

[matt-vdv]

Yeah that's one of the reasons I like tailwind, it makes reactive sites so easy whilst still being close to normal CSS.

[FrightRisk]

@cjmayo Chris, do you have any input. @hansSchall and @murfett-au also. As I mentioned, I know very little a out any of these tools because I don't do web development, but I am learning about Vue and React. At this point, we are leaning towards Vue because we want to have development continue 2 years from now and need people on the team who know how to maintain the code.
We need to get started now. Having to coordinate all other development in Discord, and web development in an issue or her in a project is challenging.
Can we take the Vue repo and start there or start somewhere else? The repo needs to be "EX-WebThrottle"

[cjmayo]

Alas no. I only write fairly small bits of plain JavaScript. I haven't looked at these frameworks.

[FrightRisk]

@cjmayo , @murfett-au , @matt-hu, @matt-vdv We really want to push this project forward and need help. Who can work with me to take over the programming and get the next version finished?

[ManiAkasapu]

I am ready to support with UX/UI/Interface related Stuff.

[matt-hu]

Sorry, but @matt-hu (me) is not the intended recipient, and someone is missing out on this thread. -------- Original message --------From: Fred ***@***.***> Date: 11/24/23 2:54 PM (GMT-08:00) To: DCC-EX/WebThrottle-EX ***@***.***> Cc: Matt Humiston ***@***.***>, Mention ***@***.***> Subject: Re: [DCC-EX/WebThrottle-EX] Consider using React for V2 (Discussion #68) @cjmayo , @murfett-au , @matt-hu, @matt-vdv We really want to push this project forward and need help. Who can work with me to take over the programming and get the next version finished? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[FrightRisk]

I spent time in "peewallup" ;) We had been speaking with @matt-hu for several years, as you can see in this thread. Are you not the same Matt? If not, is it somehow possible that he abandoned his name and someone else get it?

[matt-vdv]

Hi everyone, I did indeed change my username a while ago, I'm now matt-vdv. The other day I went to go onto discord to message you all but unfortunately my account has been suspended, currently working to get that back. Once I do I'll be able to explain the name change etc

[FrightRisk]

@hansSchall are you still with us and available to help?

[FrightRisk]

@matt-vdv What is your user name on Discord?

[hansSchall]

Sorry, I didnt have had much time and I'm still not familiar with Vue.js, but I can help with backend. One thing I could start with is a hardware-independent JS/TS abstraction of the CommandStation serial protocol (maybe as a seperate lib other projects interfaceing with DCC-EX can build on). Is there anything implemented yet (except from V1)?

[dexslab]

I was working on the backend code as well for that i have code that needs pushed to the git for some more changes and updates for the packages as everything is updated 😏

[FrightRisk]

We have some independent projects going in different directions. It would be easiest (I believe) to have our development discussions on our Discord. So far, most of us are there. @hansSchall are you there as well? @cjmayo, et all? If not, would you be willing? I believe the 3 projects that have already gotten pretty far along are @matt-vdv project and @dcyoung-dev and @dexslab. If we can all move to Discord, that would be best, but I can try to pick one of the threads here on GitHub to coordinate this if we need to. We have 2 or more discussion threads and it is hard to know where we are talking about what. Since there are existing projects, I am hoping we can put aside our feelings of attachment to a particular bit of code and vote on the best of the approaches and move it forward together. I am trying to go through all the messages in all the threads and come up with a document that distills it to something manageable in blocks of tasks. We need to look at Matt and Chris and Anthony's projects and see what we can advance from that.
It might be good to have a video call and each person presents their project so we can all get up to speed. If you read this and, I think #65? There are a ton of questions we need the answers to like Vue or React or Electron, and Webserial or Websockets, etc., etc. I am hoping we can narrow this down quickly. We can also get input from the rest of the team on Discord. While they won't code this project, there is a lot of value in their ideas of how to integrate it into the EX-CS and handle the IP issues.

[hansSchall]

It took a while, but now i have discord. My username is hansSchall.

[matt-hu]

Can I be removed from this thread going forward. Thanks, and best of luck with your project! -------- Original message --------From: Fred ***@***.***> Date: 12/1/23 11:42 AM (GMT-08:00) To: DCC-EX/WebThrottle-EX ***@***.***> Cc: Matt Humiston ***@***.***>, Mention ***@***.***> Subject: Re: [DCC-EX/WebThrottle-EX] Consider using React for V2 (Discussion #68) We have some independent projects going in different directions. It would be easiest (I believe) to have our development discussions on our Discord. So far, most of us are there. @hansSchall are you there as well? @cjmayo, et all? If not, would you be willing? I believe the 3 projects that have already gotten pretty far along are @matt-vdv project and @dcyoung-dev and @dexslab. If we can all move to Discord, that would be best, but I can try to pick one of the threads here on GitHub to coordinate this if we need to. We have 2 or more discussion threads and it is hard to know where we are talking about what. Since there are existing projects, I am hoping we can put aside our feelings of attachment to a particular bit of code and vote on the best of the approaches and move it forward together. I am trying to go through all the messages in all the threads and come up with a document that distills it to something manageable in blocks of tasks. We need to look at Matt and Chris and Anthony's projects and see what we can advance from that. It might be good to have a video call and each person presents their project so we can all get up to speed. If you read this and, I think #65? There are a ton of questions we need the answers to like Vue or React or Electron, and Webserial or Websockets, etc., etc. I am hoping we can narrow this down quickly. We can also get input from the rest of the team on Discord. While they won't code this project, there is a lot of value in their ideas of how to integrate it into the EX-CS and handle the IP issues. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[FrightRisk]

I am hoping that if we don't specifically mention matt-hu that he won't be included in this anymore, or when we create a different issue, he is not bothered. I know he can "unsubscribe" to something in the right sidebar, but not sure we have an explicit way to remove him. If he is included in something that I can remove him from, let me know

[matt-hu]

the intended Matt is on this thread but informed us that he changed his GitHub username a few months ago at the same time i signed up for GitHub to collarabe on a Bible project :)

…

On Wed, Dec 6, 2023 at 8:35 AM Fred ***@***.***> wrote: I am hoping that if we don't specifically mention matt-hu that he won't be included in this anymore, or when we create a different issue, he is not bothered. I know he can "unsubscribe" to something in the right sidebar, but not sure we have an explicit way to remove him. If he is included in something that I can remove him from, let me know — Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBUKM4OFGAEI2PX6QWHXLPDYICNDLAVCNFSM5FJ5UV52U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TONZXHA2TAMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[FrightRisk]

@hansSchall I do not see that name on Discord. The last person with "hans" in their name joined 5 months ago. Perhaps you joined Discord, but have not yet joined our channel. Click this link to join https://discord.gg/y2sB4Fp