search

DCC-EX / WebThrottle-EX

WebThrottle-EX is a web based (html,jQuery,JavaScript) Controller/Throttle for DCC-EX EX-CommandStations
https://dcc-ex.com/WebThrottle-EX
GNU General Public License v3.0
21 stars 13 forks source link

Transition to Javascript framework #57

Open matt-vdv opened 3 years ago

matt-vdv commented 3 years ago

@FrightRisk, @ManiAkasapu, I feel that in it's current state, the codebase is going to be very hard to scale, for 1.4.0, especially for the new wireless features for 1.5.0 and beyond. index.html is currently over 500 lines long, and this is only going to get longer as we add more pages such as CV programming, making it very hard to find the section you are trying to work on. As such, we need to rethink...

For this reason, I am proposing we move to Vue.js, a javascript framework. The advantages and disadvantages for this switch are as follows:

Advantages

Stays the same

Disadvantages

If we make this change, we can bear in mind the new connection methods coming in 1.5.0 like TrainLink and WiThrottle, as I think using the current codebase this would be very hard to implement. If anyone has any other suggestions, please say so, as this is the best option I could think of. I am aware that it would be a lot of work to complete, but I am happy to do the vast majority of it!

FrightRisk commented 3 years ago

Hi Matt. I'm going to have to read up on this a bit. How familiar are you with Vue.js at this point? It is likely to be around a while or will it go the way of flash?

The most important new features are CV writing and handling turnouts (and along with it, other accessories)

matt-vdv commented 3 years ago

@FrightRisk so to answer some of your questions:

Hope all of this helps!

FrightRisk commented 3 years ago

Looks good. I imagine we can change the favicon so the browser tab shows the DCC-EX rhombus logo. I'll read through the Vue.js documentation and see what I can learn. The only other issue is that it would need to be able to be picked up by others if they come onboard or if you disappear ;)

FrightRisk commented 3 years ago

What are we using now? Isn't it just JavaScript and node.js? It's been a while since I did much JavaScript, but you can use includes and still have things broken up into separate files, no? So what's the big benefit of a framework like this? And I'm not questioning your recommendation, I'm just trying to make sure we cover all the bases.

matt-vdv commented 3 years ago

@FrightRisk So at the moment, we are using pure HTML/CSS/JavaScript (no node.js). You are right in saying that you can split up JavaScript files, and we have done this a little. However, it is still hard to find JavaScript that handles a particular part of the interface. With Vue, HTML is in the same file as the related JavaScript and CSS, making it much easier to handle and reuse sections of the UI. Also, at the moment we are unable to split up the HTML page if we want it to remain a single page application. Another benefit is it allows us to use node.js which allows for much easier handling of dependences.

The real reason I suggested this is that as I looked through the code to start doing CVs, I realised that when we come to doing other connection methods (WiThrottle, TrainLink) which is next on the roadmap, it was going to be quite a bit of work to implement.

As far as learning it goes, it's pretty easy to learn if you know normal HTML etc. I can link to the video series I used to learn if that would be useful? And yes, we can certainly change the favicon :smiley:

FrightRisk commented 3 years ago

Sounds Good Matt. Let's get started (well, you already have, but officially :) ) Not sure if I mentioned it, but the WEB Serial feature that we use was released, so it is not officially in Chromium Browsers with version .89 and above. So no need to enable experimental features.

On Fri, Jun 4, 2021 at 10:10 AM Matt @.***> wrote:

@FrightRisk https://github.com/FrightRisk So at the moment, we are using pure HTML/CSS/JavaScript (no node.js). You are right in saying that you can split up JavaScript files, and we have done this a little. However, it is still hard to find JavaScript that handles a particular part of the interface. With Vue, HTML is in the same file as the related JavaScript and CSS, making it much easier to handle and reuse sections of the UI. Also, at the moment we are unable to split up the HTML page if we want it to remain a single page application. Another benefit is it allows us to use node.js which allows for much easier handling of dependences.

The real reason I suggested this is that as I looked through the code to start doing CVs, I realised that when we come to doing other connection methods (WiThrottle, TrainLink) which is next on the roadmap, it was going to be quite a bit of work to implement.

As far as learning it goes, it's pretty easy to learn if you know normal HTML etc. I can link to the video series I used to learn if that would be useful? And yes, we can certainly change the favicon 😃

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DCC-EX/WebThrottle-EX/issues/57#issuecomment-854757250, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI36OWGDACBHTAAOOUD7UQ3TRDNE7ANCNFSM43EHE4GA .

matt-vdv commented 3 years ago

Ok, thanks for letting me know about the serial stuff! That's great news as it's one less hurdle to put off potential users. I did have a look but I don't think Mozilla have anything similar in Firefox. I'll try and PR the work I've done as soon as I have time!

ManiAkasapu commented 3 years ago

Hello @FrightRisk @matt-hu, Hope you are doing good.. It is great to see this.. In addition to this I am thinking about complete revamp of UI.. I cannot Focus on code now but I can give you the new mockups that will set the design direction to Webthrottle. The aim is to build a complete interface that is simple, efficient, easy to use interface and highly modern interface.. If you both agree with me, I will start researching on this.. Thanks

matt-vdv commented 3 years ago

@ManiAkasapu sounds good by me! I haven't got very far with the Vue stuff yet so now would be the perfect time for a redesign!

TheSkellingtonKing commented 2 years ago

Will switching to multiple html pages using javascript still be stateful and maintain the connection to the base station/configuration? I don't see any session or other configuration storage other that what is common in the javascript code on the page.

ManiAkasapu commented 2 years ago

Welcome @TheSkellingtonKing Please let me know you have any questions. I am no developer so you may find most unconventional ways in the code.

@FrightRisk I have been busy with so many things (recently my second son arrived). But always ready to help on web-throttle. Just mention me on GitHub.

I see there are some pending tickets created. Before code rewrite, you want to address them?

@FrightRisk @matt-hu @TheSkellingtonKing Regarding the Rewrite ( lets call it Version 2), I think we need to do some planning. I also want to do some research to make sure that design is really meet the people expectations.

It is good that somebody who has more experience can manage the product.

matt-vdv commented 2 years ago

@ManiAkasapu regarding the open tickets, it may be best to address them before V2. That way if we borrow any code from this codebase we don't need to worry about bugs in that code.

I agree with you regarding research, I think that that is a very good idea. I wonder if there is some way we could survey current users to find out what they like and dislike etc. Unfortunately we also have no way of finding out how many people are actually using Web throttle.

FrightRisk commented 2 years ago

Let's see what we can fix and get this version where we want it while we discuss version 2.0.

People talk about WebThrottle on the Discord channel and in the video comments and on Trainboard. More people than I thought are using it. It is a great way to get started and to test. So..

Why they use it

  1. Because we talk about it on the website and in the videos
  2. It is the simplest way to get started
  3. It is the simplest way to test (you just uploaded the firmware using a computer, so easy to just load EX-WebThrottle)
  4. It's pretty

What they ask for

  1. CV editing screen. This could be the easiest program track tool out there if it had a simple CV screen and even page reads and writes like JMRI has. I'm not sure how practical the latter would be since we can't keep a table of hundreds of loco CVs. But we could ask "Enter the number of CVs" for this loco. And "Check or uncheck an CVs you need to skip". Then perhaps you can save that loco to a rosters to be able to program it again later.

  2. Turnout control - Just look at Engine Driver or some of the other throttle apps that do turnouts for ideas. Also look at JMRI.

  3. Logging/Testing/Changing Loco Address - It would be great to eliminate the need for the Arduino Serial monitor. We are almost there. If we fix the inbound logging to keep log lines together, we have a serial monitor. There may be other hooks we can include like a button for "Test Decoder" that sends . And a button for "Read Loco Address" and one for "Write Loco Address" (Those are the new and commands)

  4. Automation - This is new, but getting a ton of interest. People want to press a button and run a route with their train and trigger events like signals and crossings and automations/animations like lights going on and off, cranes loading cargo, etc. UkBloke (Chris) is very interested in working with us on ideas for how to integrate automation.

I can put out a survey on Trainboard and on Discord to get more input.

Fred

On Tue, Aug 24, 2021 at 3:14 AM Matt @.***> wrote:

@ManiAkasapu https://github.com/ManiAkasapu regarding the open tickets, it may be best to address them before V2. That way if we borrow any code from this codebase we don't need to worry about bugs in that code.

I agree with you regarding research, I think that that is a very good idea. I wonder if there is some way we could survey current users to find out what they like and dislike etc. Unfortunately we also have no way of finding out how many people are actually using Web throttle.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DCC-EX/WebThrottle-EX/issues/57#issuecomment-904384553, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI36OWFSUMHMGTXBOJWN7PDT6NBEFANCNFSM43EHE4GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

matt-vdv commented 2 years ago

Thanks for the insight! I had assumed that not many people were using it based off stars and repo clones/views. It is a shame GitHub doesn't have view figures or analytics for GitHub pages like it does repos.

Those all sound like good improvements to make, CVs and turnouts especially. What we need to try and do now is make it a great way to run a layout for advanced users, rather than just a way to get started. One thing we will need to consider carefully is whether a native app would help provide this better than a website. If so, I'm not suggesting that we take down the website, but we have a native app on offer for more advanced users who want those extra features. A couple of examples would be built in WiThrottle/TrainLink servers, custom plugins and the ability to download and flash an attached arduino when a new version of the CS is released.

FrightRisk commented 2 years ago

I'm torn on the Desktop App idea. Just to be clear, we are talking about an EXE program, correct? I'm still not a bit web app fan, but see the writing on the wall. The entire reason I had a career in computers is because the IBM PC finally made it fashionable to buy personal computers to replace mainframes and Displaywriters and have distributed processing instead of centralized with dumb terminals. We are back to centralized processing again with powerful computers just using a browser. But for the throttle, its claim to fame is that you don't have to install anything and it is universal. Any computer, any OS. That is why JMRI is successful despite it being just a mess a java code.

I'm glad you mentioned flash an arduino. That was my goal from the beginning to have EX-WebThrottle perform the following functions:

matt-vdv commented 2 years ago

@FrightRisk I see your point regarding wanting to keep it as a web app. However, some people will prefer a native app (exe) still (I know I do) as then they will be able to use it offline and won't need to have a browser open. Perhaps what we need is a web app and a native app, the web app to get people started with no download or install, then the native app for more advanced users. Some users would never need to install the native app (the conducters) whereas some of the tinkerers and the engineers would.

I have just had a bit of an idea regarding using both the web app and the native app in combination to TrainLink. You could have one laptop/PC connected to the arduino, running the native app. This would manage keeping the arduino up to date etc and have a TrainLink server built in. You could then load up the web app on your phone and use it as a throttle over TrainLink. Just a thought.

FrightRisk commented 2 years ago

You and I are in the minority, apparently. Just like I had subscriptions, yet a significant portion of software now, like all the Adobe products, are a monthly cost. I'm not sure about the run offline bit, if you click the options to install as a PWA (which you implemented?) it installs locally. If you unzip the files to a folder manually on your hard drive and click the index.html file, it runs with no internet connection. So the only difference I see is that you need a "runtime environment" I'll call it, which is a browser. So what's different between running an app that runs in a window and running code that opens an intermediary (the browser) that runs in a window? You can hide things in the browser frame and people don't even know they are in a browser. Am I missing something?

As for developing an app, then we have to talk about the language and the development environment. What would that be? How would that work? And how would that program run identically on Windows, iOS, and the varying versions of Linux? We STILL can't get the installer to work because we have issues running it cross-platform. I need someone to help with that project, BTW. In my opinion, Delphi in RAD Studio with Fire Monkey is the best thing I've ever seen. You can write cross platform, add cross platform phone apps, and it compiles with no need for dependencies like DLLs, a GAC or anything. Not interpreted, blindingly fast. But who uses it? The world seems to revolve around C#.NET now. Is that the crap we would have to deal with? And find C# programmers? Or use C++.Net? And IDEs cost money unless you can use the "free" version. I have Visual Studio Enterprise, but who else has a paid version of VS? What are your thoughts?

And I'm not against the idea, but I'm making you justify it ;) Also, I have to be practical in the things I approve (at least regarding official DCC-EX projects and products) because dealing with volunteers means that at any moment someone can become disinterested and disappear and then what are we left with? Case in point, you and Mani got busy and progress here stopped. People have school and jobs. DCC++EX works because we basically have 3 full-time programmers and a team of people with almost no drop-outs yet. So let's keep brainstorming create a roadmap. It may take a bit of back and forth to settle on what the best course is.

matt-vdv commented 2 years ago

I get your point there about native apps, and you are completly right about the PWA working offline, my mistake. My personal favourite language at the moment is Rust, although I'm not sure GUI support is great at the moment. One option would be C++ and GTK/QT with maybe some Rust componets, although it will be a lot of work. I might have another look at electron. Perhaps we need a smaller installable backend that manages things that the website can't handle like programming? They could communicate via a websocket or something. If we had a hosting platform capable of running server side programs, then we might be able to do more. However, GitHub pages is free and works fine.

Regarding subscriptions and IDEs, I fully agree with you that software is taking a worrying turn for the worst with more and more becoming software as a service when it really doesn't need to be. That's one of the reasons I have switched to Linux and try and us OSS as much as possible. My personal choice of IDE used to be VSCode with about 70 extensions but I have recently moved to Doom Emacs (basically a more modern vim, I installed the vim keybindings into VSCode once now I can't go back). Haven't used it much yet but its been good so far.

I'll take a look at Delphi, I haven't heard of that. As I said I have learnt Rust recently and I am really enjoying it (think C++ with memory safety and better error handling). Its a pretty modern language and combines the best parts of many languages, in my opinion.

I fully understand what you are saying about project management and it is a good idea to think this through, rather than just rushing in. Hopefully over time we can get some more people onboard to help speed up development.

TheSkellingtonKing commented 2 years ago

Wow, lots of good conversation.

So my strength is in Microsoft products and javascript/node/etc. Ive seen rust, I've seen Delphi but have not done any coding on those platforms.

Trying to get a common set of code that can run on everything will be a difficult task. I was at a conference recently and saw a demo of .net Maui, which can create native apps on Android, IOS, windows and macos. But won't do web or Linux. We could look to have some sort of common set of code/components that can be reusable for each different platform as a possibility but then we need to code each platform. We may need to make a decision on what platforms we want to (or can to start) support.

Platform aside, I strongly believe we can get all of the things above done in the website. It will need to be multiple page, possibly using vue or some other set of javascript. Without a doubt we will need state management so that the site remembers the user and moving between pages. Another concern of mine is using web local storage which ties you to a specific machine and your configuration. Machine dies and you lose all that configuration. Without local storage that means needing a backend database. And this pushes us down the road of using hosted sites somewhere for a site.

In the end I think the web platform is the best as it runs across all environments? Running offline might be hard if we want an online configuration.

Jeff

On Wed, Aug 25, 2021, 9:43 AM Matt @.***> wrote:

I get your point there about native apps, and you are completly right about the PWA working offline, my mistake. My personal favourite language at the moment is Rust, although I'm not sure GUI support is great at the moment. One option would be C++ and GTK/QT with maybe some Rust componets, although it will be a lot of work. I might have another look at electron. Perhaps we need a smaller installable backend that manages things that the website can't handle like programming? They could communicate via a websocket or something. If we had a hosting platform capable of running server side programs, then we might be able to do more. However, GitHub pages is free and works fine.

Regarding subscriptions and IDEs, I fully agree with you that software is taking a worrying turn for the worst with more and more becoming software as a service when it really doesn't need to be. That's one of the reasons I have switched to Linux and try and us OSS as much as possible. My personal choice of IDE used to be VSCode with about 70 extensions but I have recently moved to Doom Emacs (basically a more modern vim, I installed the vim keybindings into VSCode once now I can't go back). Haven't used it much yet but its been good so far.

I'll take a look at Delphi, I haven't heard of that. As I said I have learnt Rust recently and I am really enjoying it (think C++ with memory safety and better error handling). Its a pretty modern language and combines the best parts of many languages, in my opinion.

I fully understand what you are saying about project management and it is a good idea to think this through, rather than just rushing in. Hopefully over time we can get some more people onboard to help speed up development.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DCC-EX/WebThrottle-EX/issues/57#issuecomment-905563505, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUUE5UJWDW5OHQFAE2ZJY6LT6T6PZANCNFSM43EHE4GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

dexslab commented 2 years ago

So i was reading thru and saw the potential to change to Vue. This is a great idea and technically we can use something like electron or various to port them directly as a desktop app to various devices. I personally use Vue but in typescript so i have better control over variable types. Me and Mani at one point were working on an application using Flutter that allows it to become a native app on Android and iOS so we have the mobile space as well. VueJS is really nice and great way to keep up to date. If we do i do suggest we use typescript so that its a lot easier to read and understand than base javascript. As the components in VueJS can get a bit confusing when you are making a ton of them and importing them and using them. Just my opinion. But it would also allow me to help out more with the Throttle as I dont write basic html/js/css sites anymore 😄

murfett-au commented 2 years ago

I’d like to suggest React as an option instead of vue. I have used both professionally, and they are both good products and have much in common. @matt-hu mentions React above and suggests Vue is an open source alternative to React, but both React and Vue are open source. React was written by Facebook, but they have published all source code and it is maintained as open source software.

React is a lot more popular than Vue. Vue had 2.6 million downloads last week, and Reacthad over 11 million. This means there are more packages available to assist which saves time, and more developers who can assist.

Most importantly, I can get started now!

React is also suitable for local non internet connected operation, as it builds into a (large) set of static JavaScript files, so you can put these in a folder on your PC and he a browser to “run” the site.

I don’t want this to turn into a religious argument of Vue vs React, but starting a new project in 2021 in Vue instead of React, especially if it is based on an assumption that React is a proprietary Facebook product, would be backing the wrong horse.

FrightRisk commented 2 years ago

Well @murfett-au, you've done what I always ask of people who have an idea, "sell it" ;) Hopefully, the best argument wins out. Don't worry about egos, so far anyway, we have been able to keep that out of things despite having such a large group. Some questions:

React is lighter than Vue, has a larger user base and more libraries.

Which will be here in 5 years? Beta was better than VHS, it lost. Now we have neither. React has a larger user base, but it is split into factions and there seems to be confusion surrounding it. Coming out after React, Vue has already passed Angular. Will it catch up with React? My only concern here is that the ease of use and documentation will have people gravitate towards it and surpass React. I was able to understand Vue in a day. I still don't understand React, but don't have to, that's the job for you guys. But I would learn it if we decided to use it.

Vue is easier to learn than React and uses a more familiar model in the way it handles CSS and HTML. Would we use JSX if we use React? Vue puts the style tags in the code, which also makes it much easier to read and not have to cross reference a CSS file to see what's going on. Would we want to use a component like "Emotion" to provide something similar? Would we need the "classNames" library?

What is the development process for each? What does a programmer need to install and how does translate to the user and what they need on their end? How does this work with the progressive web app feature we have now? We click a button and the browser makes it a PWA and installs it locally.

We would have more libraries to use right now with React. Which ones might we use? How do we replicate the look and feel of what we have now with the round button and vertical slider, etc. Can we get an LCD display widget?

So all that said, we need to move forward and that depends on volunteers. The person who promises to do the work gets a disproportionate vote as to the tools we use ;) My biggest concern is the reality that projects like ours, get a person for about 6 months to a year and they disappear. Then what happens to the project? I hope that doesn't happen, but we do need to find people to pick it up and understand the code if it does.

Thanks for your suggestions John. I look forward to a short discussion with everyone and making a decision.

@dexslab @ManiAkasapu @matt-hu could you adapt to React?

-Fred

matt-vdv commented 2 years ago

Hi Fred,

Just thought I should say, due to other commitments my input commits wise will be minimal unfortunately. That being said it is possible I could adapt to React. I went for Vue for a similar reason to what you said earlier, not trusting Facebook. However, I've heard they are similar so I'm sure I could manage to adapt with a bit of practice.

dexslab commented 2 years ago

Well you want me to sell it how about some demonstrations of Vue framework. I have used Vue going on a few years now and i love it. I have written multiple sites and various UIs in Vue. I used to use Ionic (Angular2) in TS but again fragmentation in angular and high learning curve made it more difficult. I have a total project in angular which is still hard to understand and i still cannot. Vue i got in a matter of a few days started writing and boom was good to go. .Vuetify makes setting up UI so easy and able to be duplicated in other components. I would recommend we move to typescript and there are plenty of libraries and such to achieve what you want. So here is a link to a video that you can watch of a UI i made a bit ago with Vue and Vuetify

https://drive.google.com/file/d/1BTb8O3EzipnW4nZLjIGbY5NI-SwTrNOa/view?usp=sharing

If you would prefer a live demo let me know i can set up multiple sites. Also if we get the installer built into the website and figure out how we are going to do that then Vuetify i could get setup a wizard in a few moments.

FrightRisk commented 2 years ago

That does look nice. I think both do very similar things. We have more packages with React. Bottom line is that no one has worked on the new things we agreed to do, therefore, whoever commits to moving this forward in the next few days, gets to have the most input into which tool we will use. @murfett-au , what can React do that Vue can't? Having used both, what do you prefer about it other than more people using it and it has a lot of packages?

What does the setup and development process look like? For example, our WEB stuff using Sphinx, requires a developer to install Python, then the sphinx stuff, then download our repository, download PlatformIO and a couple of plugins (or use some editor in restructured text format and sacrifice a bunch of features), run a batch file to build everything, then look at the HTML files it generates in a browser, etc. Hardly anyone is going to want to do that. At least we can accept text files in RST format they edit themselves and we do the hard part. How painless would it be for someone to be coding and uploading things to GitHub?

TheSkellingtonKing commented 2 years ago

React is a download. It's part of node.js, and developers would need to install another tool called npm (node package manager). It can be coded and run in the free IDE Visual Studio Code. There are others, but I have experience with that IDE so it's my preferred tool.

I am not sure if it can be compiled into a stand alone application, nor am I sure if Vue can do the same thing.

With regards to future work/developers I think it just comes down to picking one and going with it. That question/concern is going to be the same no matter what tool.

I am willing to spin up a basic sample app in React and try to hook it up to make calls to DCC++ to turn the track on/off as an example, if that seems like it would be something the team was interested in. The code can be checked into Github the same way it is now. I am not sure how deploys would work right now, but it can be figured out.

Jeff

On Thu, Oct 7, 2021 at 11:58 AM Fred @.***> wrote:

That does look nice. I think both do very similar things. We have more packages with React. Bottom line is that no one has worked on the new things we agreed to do, therefore, whoever commits to moving this forward in the next few days, gets to have the most input into which tool we will use. @murfett-au https://github.com/murfett-au , what can React do that Vue can't? Having used both, what do you prefer about it other than more people using it and it has a lot of packages?

What does the setup and development process look like? For example, our WEB stuff using Sphinx, requires a developer to install Python, then the sphinx stuff, then download our repository, download PlatformIO and a couple of plugins (or use some editor in restructured text format and sacrifice a bunch of features), run a batch file to build everything, then look at the HTML files it generates in a browser, etc. Hardly anyone is going to want to do that. At least we can accept text files in RST format they edit themselves and we do the hard part. How painless would it be for someone to be coding and uploading things to GitHub?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DCC-EX/WebThrottle-EX/issues/57#issuecomment-937981719, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUUE5UOKY5Y3JU4DXN54K7TUFXGUBANCNFSM43EHE4GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

FrightRisk commented 2 years ago

Let's try that demo in React and see how it will go. DCC-EX uses VSC for all development, with PlatformIO being the extension used for developing C++ projects that will run on the Arduinos and other microcontrollers. Even the website is written using VSC with extensions for RST files and live viewing the pages.

What we have now with WebThrottle allows us to run it from the webserver, download a zip file and just unzip it to a folder and run the HTML files locally, or use the Progressive Web App (PWA) capability from a button on the settings page to install it as an App. We would not want to lose any of these capabilities. People don't always want to use a web page and are not always connected to the internet. If a user has to do anything more than unzip things to a folder, I'm not sure that will work. So bear with me as I learn more about what you are trying to do.

Will the controls and look and feel we have now, be the same or similar?

Fred

ManiAkasapu commented 2 years ago

If you guys need any resources/assets (images, icons etc) please feel free to contact me.

TheSkellingtonKing commented 2 years ago

Well, the reality with react is that it can repackage other js, so my initial thought is that we could leverage some parts of the existing UI. I am not sure how far we want to go down that path because there may some newer/already built UI interfaces that we might be able to leverage - and maybe look for one with a similar look and feel. The advantage to using those is they are already built and tested, so our effort would be to embed our controller calls in them. The backend code includes would most likely stay the same - the stuff that controls the DCC.

My goal is to have just the basic controls as part of this test - connect to my DCC, turn on track power, then attach/turn on a loco. I got my new motor shield today so have a separate test rig now to develop with. With the demo in place we can determine if we can package up and download a copy to run local.

Jeff

On Fri, Oct 8, 2021 at 7:54 AM Fred @.***> wrote:

Let's try that demo in React and see how it will go. DCC-EX uses VSC for all development, with PlatformIO being the extension used for developing C++ projects that will run on the Arduinos and other microcontrollers. Even the website is written using VSC with extensions for RST files and live viewing the pages.

What we have now with WebThrottle allows us to run it from the webserver, download a zip file and just unzip it to a folder and run the HTML files locally, or use the Progressive Web App (PWA) capability from a button on the settings page to install it as an App. We would not want to lose any of these capabilities. People don't always want to use a web page and are not always connected to the internet. If a user has to do anything more than unzip things to a folder, I'm not sure that will work. So bear with me as I learn more about what you are trying to do.

Will the controls and look and feel we have now, be the same or similar?

Fred

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DCC-EX/WebThrottle-EX/issues/57#issuecomment-938619619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUUE5UNWDPCKHQEXEMRQ6LTUF3SXTANCNFSM43EHE4GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

TheSkellingtonKing commented 2 years ago

I've got the base application up and running via react and it can see the arduino. I'm working on trying to package it as an app to make sure it can be done before we go further. I've got a lead and am working on it.

On Fri, Oct 8, 2021 at 11:31 PM Jeff Fulcer @.***> wrote:

Well, the reality with react is that it can repackage other js, so my initial thought is that we could leverage some parts of the existing UI. I am not sure how far we want to go down that path because there may some newer/already built UI interfaces that we might be able to leverage - and maybe look for one with a similar look and feel. The advantage to using those is they are already built and tested, so our effort would be to embed our controller calls in them. The backend code includes would most likely stay the same - the stuff that controls the DCC.

My goal is to have just the basic controls as part of this test - connect to my DCC, turn on track power, then attach/turn on a loco. I got my new motor shield today so have a separate test rig now to develop with. With the demo in place we can determine if we can package up and download a copy to run local.

Jeff

On Fri, Oct 8, 2021 at 7:54 AM Fred @.***> wrote:

Let's try that demo in React and see how it will go. DCC-EX uses VSC for all development, with PlatformIO being the extension used for developing C++ projects that will run on the Arduinos and other microcontrollers. Even the website is written using VSC with extensions for RST files and live viewing the pages.

What we have now with WebThrottle allows us to run it from the webserver, download a zip file and just unzip it to a folder and run the HTML files locally, or use the Progressive Web App (PWA) capability from a button on the settings page to install it as an App. We would not want to lose any of these capabilities. People don't always want to use a web page and are not always connected to the internet. If a user has to do anything more than unzip things to a folder, I'm not sure that will work. So bear with me as I learn more about what you are trying to do.

Will the controls and look and feel we have now, be the same or similar?

Fred

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DCC-EX/WebThrottle-EX/issues/57#issuecomment-938619619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUUE5UNWDPCKHQEXEMRQ6LTUF3SXTANCNFSM43EHE4GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

TheSkellingtonKing commented 2 years ago

Ok, so I have been able to create an app using react-native which is considered a 'mobile' version of react. It uses the same format, but things are a little different here and there. The main part is that it allows me to do react-native-ios, react-native-web, react-native-windows, and react-native-android. I think that means we might be able to create installable versions for each platform but I've not dug down into that yet. Considering right now this is USB only I'm not sure if it would even matter for IOS and Android. Right now I'm only really paying attention to react-native-windows and my app can install itself on my Windows 10 machine as part of my build/development but I don't know yet how to make it into an MSI for windows installation yet. I have a ways to go and I really only have the base app done (think 'Sample Hello World' app), it doesn't even talk to the controller properly yet.

My concern is that this is going to increase the complexity in order to support web and windows at the same time. With the increased complexity, we are going down a path of limiting how many and which developers might be able to help out with this code. If we stick with just javascript that leaves us with more options for developers and help.

I am not sure if Vue would make it easier but I don't know Vue so I can't say.

I can continue down this path and get a basic version that talks to the controller and share the code with the team to review to start. I know I said that's what I was going to do, but the complexity has increased and I wanted to stop and ask. What are your thoughts?

Jeff

On Thu, Oct 14, 2021 at 8:40 PM Jeff Fulcer @.***> wrote:

I've got the base application up and running via react and it can see the arduino. I'm working on trying to package it as an app to make sure it can be done before we go further. I've got a lead and am working on it.

On Fri, Oct 8, 2021 at 11:31 PM Jeff Fulcer @.***> wrote:

Well, the reality with react is that it can repackage other js, so my initial thought is that we could leverage some parts of the existing UI. I am not sure how far we want to go down that path because there may some newer/already built UI interfaces that we might be able to leverage - and maybe look for one with a similar look and feel. The advantage to using those is they are already built and tested, so our effort would be to embed our controller calls in them. The backend code includes would most likely stay the same - the stuff that controls the DCC.

My goal is to have just the basic controls as part of this test - connect to my DCC, turn on track power, then attach/turn on a loco. I got my new motor shield today so have a separate test rig now to develop with. With the demo in place we can determine if we can package up and download a copy to run local.

Jeff

On Fri, Oct 8, 2021 at 7:54 AM Fred @.***> wrote:

Let's try that demo in React and see how it will go. DCC-EX uses VSC for all development, with PlatformIO being the extension used for developing C++ projects that will run on the Arduinos and other microcontrollers. Even the website is written using VSC with extensions for RST files and live viewing the pages.

What we have now with WebThrottle allows us to run it from the webserver, download a zip file and just unzip it to a folder and run the HTML files locally, or use the Progressive Web App (PWA) capability from a button on the settings page to install it as an App. We would not want to lose any of these capabilities. People don't always want to use a web page and are not always connected to the internet. If a user has to do anything more than unzip things to a folder, I'm not sure that will work. So bear with me as I learn more about what you are trying to do.

Will the controls and look and feel we have now, be the same or similar?

Fred

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DCC-EX/WebThrottle-EX/issues/57#issuecomment-938619619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUUE5UNWDPCKHQEXEMRQ6LTUF3SXTANCNFSM43EHE4GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

FrightRisk commented 2 years ago

Well, the Web Throttle is languishing as often happens with open source projects, people lose interest or get busy and there is no one left for updates. I hope someone can get this going again. We are about to release version 4.0 of DCC++EX and there are lots of additions. I mentioned some above, but having buttons to read the loco address and write a new address and have screens for CV reads and writes and Turnout control is pretty important. With EX-RAIL Automation, we can offer a place to write scripts, or at least provide buttons like Engine Driver does to run "routes" and automations. Can anyone help me add a few things even if we don't do an overhaul with Vue or whatever?

Best,

Fred

On Sun, Oct 17, 2021 at 11:00 PM TheSkellingtonKing < @.***> wrote:

Ok, so I have been able to create an app using react-native which is considered a 'mobile' version of react. It uses the same format, but things are a little different here and there. The main part is that it allows me to do react-native-ios, react-native-web, react-native-windows, and react-native-android. I think that means we might be able to create installable versions for each platform but I've not dug down into that yet. Considering right now this is USB only I'm not sure if it would even matter for IOS and Android. Right now I'm only really paying attention to react-native-windows and my app can install itself on my Windows 10 machine as part of my build/development but I don't know yet how to make it into an MSI for windows installation yet. I have a ways to go and I really only have the base app done (think 'Sample Hello World' app), it doesn't even talk to the controller properly yet.

My concern is that this is going to increase the complexity in order to support web and windows at the same time. With the increased complexity, we are going down a path of limiting how many and which developers might be able to help out with this code. If we stick with just javascript that leaves us with more options for developers and help.

I am not sure if Vue would make it easier but I don't know Vue so I can't say.

I can continue down this path and get a basic version that talks to the controller and share the code with the team to review to start. I know I said that's what I was going to do, but the complexity has increased and I wanted to stop and ask. What are your thoughts?

Jeff

On Thu, Oct 14, 2021 at 8:40 PM Jeff Fulcer @.***> wrote:

I've got the base application up and running via react and it can see the arduino. I'm working on trying to package it as an app to make sure it can be done before we go further. I've got a lead and am working on it.

On Fri, Oct 8, 2021 at 11:31 PM Jeff Fulcer @.***> wrote:

Well, the reality with react is that it can repackage other js, so my initial thought is that we could leverage some parts of the existing UI. I am not sure how far we want to go down that path because there may some newer/already built UI interfaces that we might be able to leverage - and maybe look for one with a similar look and feel. The advantage to using those is they are already built and tested, so our effort would be to embed our controller calls in them. The backend code includes would most likely stay the same - the stuff that controls the DCC.

My goal is to have just the basic controls as part of this test - connect to my DCC, turn on track power, then attach/turn on a loco. I got my new motor shield today so have a separate test rig now to develop with. With the demo in place we can determine if we can package up and download a copy to run local.

Jeff

On Fri, Oct 8, 2021 at 7:54 AM Fred @.***> wrote:

Let's try that demo in React and see how it will go. DCC-EX uses VSC for all development, with PlatformIO being the extension used for developing C++ projects that will run on the Arduinos and other microcontrollers. Even the website is written using VSC with extensions for RST files and live viewing the pages.

What we have now with WebThrottle allows us to run it from the webserver, download a zip file and just unzip it to a folder and run the HTML files locally, or use the Progressive Web App (PWA) capability from a button on the settings page to install it as an App. We would not want to lose any of these capabilities. People don't always want to use a web page and are not always connected to the internet. If a user has to do anything more than unzip things to a folder, I'm not sure that will work. So bear with me as I learn more about what you are trying to do.

Will the controls and look and feel we have now, be the same or similar?

Fred

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/DCC-EX/WebThrottle-EX/issues/57#issuecomment-938619619 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AUUE5UNWDPCKHQEXEMRQ6LTUF3SXTANCNFSM43EHE4GA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DCC-EX/WebThrottle-EX/issues/57#issuecomment-945320309, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI36OWBOOGWIKBEFX3E5OXLUHOETPANCNFSM43EHE4GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

ManiAkasapu commented 2 years ago

@FrightRisk There are some pull requests from @dcyoung-dev. Have you looked at them? Also please prioritize the the things among existing issues and new features you wanted to see. I will try to work on them (but not as fast as I used to)

hansSchall commented 1 year ago

I am new to WebThrottle-EX development, but I want to help improving this quite usefull tool.

I already created a few apps using TypeScript, React, Node.js and electron.js.

In general I would suggest to migrate to TypeScript as it simplyfies development and debugging a LOT. Because valid JavaScript is always valid TypeScript this migration could be done component per component.

I would prefer using React because I am used to it, but I would have no problem with Vue.

As I saw some mentions of new features like CV programming: I see WebThrottle-EX as a tool for testing your hardware setup. So there are some features it should have:

One other suggestion: I would add (additionally to WebSerial) the feature to run the whole app on a local web server (node.js). This has some advantages:

  1. You can run the app on your mobile phone (needs to be in the same network)
  2. Independence of WebSerial, because it is still labeled experimental/may change in the future
  3. With a good Node.js or HTTP API developers (like I) would be able to build their own controller software that exactly suits their needs.

Please let me known your opinion about the last suggestion.

FrightRisk commented 1 year ago

I would love for someone to help with new development. There are lots of new features and commands in EX-CommandStation that should be in EX-WebThrottle (we have standardized on EX being the prefix for all our products)

We need to add CV Programming, a turnout control screen, and hooks for EX-RAIL. I see WebThrottle as both a throttle a d a tool for testing and even ultimately, an installer.

Let's talk. Once we have someone to take charge of the new development, I hope I can get others to help like Matt, Jeff, etc.

I need to read about all these tools. What is the development process? What has to be installed? What IDE(s) can you use for development? We use PlatformIO for development of the Command Station and the website. It would be nice not to have to have gigabytes of other software and have to learn a completely new development workflow, but perhaps that is unavoidable. What can you share about the development process steps?

Fred

hansSchall commented 1 year ago

I use VScode for everything. By the way, VScode itself is written in TypeScript and Electron.js and has great TS/JS tooling builtin.

Most of js/ts tools can be installed with npm, because they are implemented itself in js/Node.js. npm is the package manager of Node.js. So you will need to install Node.js from https://nodejs.org/. Simply install it using the default options.

Node.js is a JavaScript runtime based on chromes V8 engine with some interfacing APIs. To test it, create a .js file with a single console.log statement inside. Run node <your filename>.js.

Some links about typescript that might be usefull:

// about TypeScript in general https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html

// install typescript tools https://www.typescriptlang.org/docs/handbook/typescript-tooling-in-5-minutes.html

// typescript playground: great for trying things out https://www.typescriptlang.org/play

// best feature of tsc ever: tsc -w or tsc --watch. Whenever a input file changes the compiler starts again and takes <= 1s

dexslab commented 1 year ago

I started a typescript vue3 project for those with developer access feel free to look it over and make changes. I have been busy and haven't looked back around to it yet.

FrightRisk commented 1 year ago

We have 2 other developers, Matt and John, who I may be able to help. I think the choice has to be made between Vue and React. I'm torn in that Vue has some nice features and may be easier to integrate into an existing app, but React is the VHS to Vue's BetaMax. Maybe it is more Android vs. iPhone, but despite 8 years to catch up, React still has the big lead. If someone starts this project and drops out, it would be a lot easier to find a React programmer.

I really like what @matt-hu started, but I would need a commitment from him and agreement on if he is willing to stand behind Vue or compromise and work with us on React. @cjmayo, @murfett-au, are you still with us and willing to help?

And do we keep going in this issue, go to this discussion : https://github.com/DCC-EX/WebThrottle-EX/discussions/68 and work there, or do Discord. At the time, Matt could not do Discord.

I really appreciate the help and I would like to start right away, lets have a short discussion, pick a tool and go. I am leaning towards React, just because we have potentially 2 people who know it and it has a much bigger base. If anyone wants to convince me why that is not the way to go, sell me. And if we choose React, can you still help Matt? If we choose Vue, can you other gentlemen still help?

I just did a crash course on the differences between both and looked at the code. React is a library, while Vue is a Framework. There is a build process with Vue. Is there one for React? While JSX looked like a bit to learn, both tools use props and objects (though they are managed differently, and both use the DOM. I don't think other than installing a library, working with React requires anything special. Seems to me it is mostly a syntactical difference and that React would be more familiar to C++ programmers.

I will do some more reading. Thoughts?

Fred

ManiAkasapu commented 1 year ago

It good to hear that finally someone to keep this going.. Let me know if you need any help wrt to present code, images, ideas ..

cjmayo commented 1 year ago

I still exist, but this is the model of controller I am using: controller No JavaScript required! (I haven't actually used any of these frameworks, so don't have anything particular to add).

matt-vdv commented 1 year ago

Hi all,

Unfortunately I'm not going to be able to make the commitment to allow for the use of Vue. However I have heard that they are fairly similar and once you know one learning the other is fairly easy.

As I have a busy few months coming up I won't be able to contribute much in the way of code, but I'd love to still be involved in the project possibly doing some of the more 'admin' tasks such as dealing with bug reports, reviewing and merging prs, writing docs along with the occasional bug fix if I get time.

Once I'm a little less busy I'd really like to get back to contributing code though!

Matt

FrightRisk commented 1 year ago

Remember what we have here, we are not an Enterprise level website with a shopping cart (though an interesting idea is to be able to purchase things... But I digress), we are just an app to control trains. Which parts are necessary and which parts are just because that is what someone knows and uses in their day job? If the only choice is Vue vs. React, then we have to make it.

FrightRisk commented 1 year ago

I'm not 100% (in hospital) so not able to lead this as I would like. I created a new repo and DRc has one also do the Vue version. Does that help us at least with deciding a direction?

Chris mentioned to me, ' the overriding issue for webthrottle is that there can be no background server processes other than supplying fixed files. (So no node.js) and the comms to the cs will have to be dual pathed over the serial link (for backward compatibility and uno support) or websockets (the most appropriate protocol) for wifi/eth cs which still needs implementing." Comments?

FrightRisk commented 1 year ago

Important note that EX-CommandStation sends everything over Serial 0 (USB). All diags go there. A"<" knows it is a DCC++ command, otherwise a different parser looks for a WiThrottle command. When connecting to the other serial ports via WiFi or Ethernet, we try to respond to the device sending the command but there is no negotiation. It is just an open serial port. Looking at the WiThrottle code or wifi code will show how it works.

matt-vdv commented 1 year ago

@FrightRisk So sorry to hear that, hope you are feeling better soon.

I think we are getting some sort of idea as to where we are heading from the talk in the discussion and we'll move to the new repo. Once that's done there'll be a few things we might need you to do such as set up github pages and branch restrictions seen as we don't have the permissions to do that as far as I am aware.

dexslab commented 1 year ago

Well I'm gonna just leave this video here so you can at least laugh a bit.

https://youtu.be/HyWYpM_S-2c