Terminal I/O UI
-
So, I have a system I am pitching to migrate to something modern. It was written in the early 80s using a VT terminal interface to a VAX. The customer has attempted to redevelop, migrate, re do this system about a 1/2 dozen times, all ending in failure. What keeps getting miss is that, at the end of the day, the system works. Production knows how to rapidly enter jobs to produce the product. So, picture a UI that is a series of terminal input. I guess the closest analogy would be entering prompts at the command prompt level. I really don't want to continue in this direction, but the UI is key to the effectiveness of the system. Unlike Microsoft, I abhor screwing with users. It's important that phase 1 of the new project look and behave exactly like the existing system. Any suggestions for libraries or toolkits. I don't care if I have to buy a license. The UI is the most evident thing about this application. There are users that are simply wizards at flying through the terminal based interface. I also have to migrate from flat files to an RDB and replace all of the report code with a modern report writer but that's another issue.
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
Okay, some images. Basically the users whip through the menu processing and thundering into data entry. UI presentation 1 is I want to mimic this behavior. https://ibb.co/FXCWY2m https://ibb.co/rtTVt5S https://ibb.co/rtTVt5S
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
-
Okay, some images. Basically the users whip through the menu processing and thundering into data entry. UI presentation 1 is I want to mimic this behavior. https://ibb.co/FXCWY2m https://ibb.co/rtTVt5S https://ibb.co/rtTVt5S
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
Well, if they're used to using a thin client / mainframe like that over SSH and you don't want to lose that concept of thin client and/or the app is on the way out anyway, you really only have three options (ignoring MS's butchering of the term smart client in WPF, etc.). 1 Check out [Ncurses](https://en.wikipedia.org/wiki/Ncurses). It's a 100% terminal based UI library and totally free. It's a C library but I'm sure you can find bindings for it just about any language. You can spice it up a little and lose zero of the thin client goodness and everything is 100% terminal based. 2 You can replace that old UI as a web page pretty easy, and you can make it look exactly the same. It's still considered thin client / mainframe as only the browser is required. There are tons of [examples](https://github.com/m4tt72/terminal) out there that mimic a console for the web. 3 As mentioned, if the app is going to die anyway... then just do nothing and let it die.
Jeremy Falcon
-
Well, if they're used to using a thin client / mainframe like that over SSH and you don't want to lose that concept of thin client and/or the app is on the way out anyway, you really only have three options (ignoring MS's butchering of the term smart client in WPF, etc.). 1 Check out [Ncurses](https://en.wikipedia.org/wiki/Ncurses). It's a 100% terminal based UI library and totally free. It's a C library but I'm sure you can find bindings for it just about any language. You can spice it up a little and lose zero of the thin client goodness and everything is 100% terminal based. 2 You can replace that old UI as a web page pretty easy, and you can make it look exactly the same. It's still considered thin client / mainframe as only the browser is required. There are tons of [examples](https://github.com/m4tt72/terminal) out there that mimic a console for the web. 3 As mentioned, if the app is going to die anyway... then just do nothing and let it die.
Jeremy Falcon
But I want the money :). I've had to deal with requests over the last 20 years that are simply not possible with the current system. They keep trying to replace it without talking to the people that use it and know it. I'm just looking for something that will allow me to replicate the speed of the terminal environment. I'll check into the links.
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
-
So, I have a system I am pitching to migrate to something modern. It was written in the early 80s using a VT terminal interface to a VAX. The customer has attempted to redevelop, migrate, re do this system about a 1/2 dozen times, all ending in failure. What keeps getting miss is that, at the end of the day, the system works. Production knows how to rapidly enter jobs to produce the product. So, picture a UI that is a series of terminal input. I guess the closest analogy would be entering prompts at the command prompt level. I really don't want to continue in this direction, but the UI is key to the effectiveness of the system. Unlike Microsoft, I abhor screwing with users. It's important that phase 1 of the new project look and behave exactly like the existing system. Any suggestions for libraries or toolkits. I don't care if I have to buy a license. The UI is the most evident thing about this application. There are users that are simply wizards at flying through the terminal based interface. I also have to migrate from flat files to an RDB and replace all of the report code with a modern report writer but that's another issue.
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
I am not certain I fully understand your intention but permit me to say I am looking forward to learning the GUI library "Dear ImGui" as it is impressively fast and am rather fond of its appearance.
-
Okay, some images. Basically the users whip through the menu processing and thundering into data entry. UI presentation 1 is I want to mimic this behavior. https://ibb.co/FXCWY2m https://ibb.co/rtTVt5S https://ibb.co/rtTVt5S
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
My article :: CommScript[^] :: is how I dealt with automating data entry via such a system about twenty years ago. I doubt that will you in your endeavor.
-
So, I have a system I am pitching to migrate to something modern. It was written in the early 80s using a VT terminal interface to a VAX. The customer has attempted to redevelop, migrate, re do this system about a 1/2 dozen times, all ending in failure. What keeps getting miss is that, at the end of the day, the system works. Production knows how to rapidly enter jobs to produce the product. So, picture a UI that is a series of terminal input. I guess the closest analogy would be entering prompts at the command prompt level. I really don't want to continue in this direction, but the UI is key to the effectiveness of the system. Unlike Microsoft, I abhor screwing with users. It's important that phase 1 of the new project look and behave exactly like the existing system. Any suggestions for libraries or toolkits. I don't care if I have to buy a license. The UI is the most evident thing about this application. There are users that are simply wizards at flying through the terminal based interface. I also have to migrate from flat files to an RDB and replace all of the report code with a modern report writer but that's another issue.
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
First of all, you need to learn the communication protocol between the VT terminal and VAX. Only when you understand completely, how they talk between them, you can start your application design. Since terminals from these old days where dumb devices, I suspect that this communication protocol is heavily based on the VT terminal features (only my guess). So, VAX knows exactly, which terminal it is talking with, and sends terminal-specific data to it. Learning the VT terminal reference is another necessary step. So, your task is to write VT terminal emulation. VAX should believe that it is talking with VT. End user may see an exact copy of the terminal or something else, like full-featured GUI application - this is less important. Finally, such tasks are usually solved by complete terminal emulation also for end user. Not surprising, this is a lot of work. Make a Google search for "VT terminal emulation". You are not the first person, who needs to implement such functionality. Maybe some existing emulation can do something that you need. Long time ago I was working in the company, that made a great business developing an old terminals emulation - for similar purposes.
-
So, I have a system I am pitching to migrate to something modern. It was written in the early 80s using a VT terminal interface to a VAX. The customer has attempted to redevelop, migrate, re do this system about a 1/2 dozen times, all ending in failure. What keeps getting miss is that, at the end of the day, the system works. Production knows how to rapidly enter jobs to produce the product. So, picture a UI that is a series of terminal input. I guess the closest analogy would be entering prompts at the command prompt level. I really don't want to continue in this direction, but the UI is key to the effectiveness of the system. Unlike Microsoft, I abhor screwing with users. It's important that phase 1 of the new project look and behave exactly like the existing system. Any suggestions for libraries or toolkits. I don't care if I have to buy a license. The UI is the most evident thing about this application. There are users that are simply wizards at flying through the terminal based interface. I also have to migrate from flat files to an RDB and replace all of the report code with a modern report writer but that's another issue.
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
Maybe this would be of interest to you: Get the Best of Both Worlds: Command Line and GUI[^]
-
Well, if they're used to using a thin client / mainframe like that over SSH and you don't want to lose that concept of thin client and/or the app is on the way out anyway, you really only have three options (ignoring MS's butchering of the term smart client in WPF, etc.). 1 Check out [Ncurses](https://en.wikipedia.org/wiki/Ncurses). It's a 100% terminal based UI library and totally free. It's a C library but I'm sure you can find bindings for it just about any language. You can spice it up a little and lose zero of the thin client goodness and everything is 100% terminal based. 2 You can replace that old UI as a web page pretty easy, and you can make it look exactly the same. It's still considered thin client / mainframe as only the browser is required. There are tons of [examples](https://github.com/m4tt72/terminal) out there that mimic a console for the web. 3 As mentioned, if the app is going to die anyway... then just do nothing and let it die.
Jeremy Falcon
"There are tons of examples out there that mimic a console for the web." This is the phrase I was looking for. It's a console app. I'll look things up.
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
-
First of all, you need to learn the communication protocol between the VT terminal and VAX. Only when you understand completely, how they talk between them, you can start your application design. Since terminals from these old days where dumb devices, I suspect that this communication protocol is heavily based on the VT terminal features (only my guess). So, VAX knows exactly, which terminal it is talking with, and sends terminal-specific data to it. Learning the VT terminal reference is another necessary step. So, your task is to write VT terminal emulation. VAX should believe that it is talking with VT. End user may see an exact copy of the terminal or something else, like full-featured GUI application - this is less important. Finally, such tasks are usually solved by complete terminal emulation also for end user. Not surprising, this is a lot of work. Make a Google search for "VT terminal emulation". You are not the first person, who needs to implement such functionality. Maybe some existing emulation can do something that you need. Long time ago I was working in the company, that made a great business developing an old terminals emulation - for similar purposes.
Nah, no need to know the protocol of anything. As Jeremy pointed out, it's a "simple" console app - well simple in terms of 200K lines of FORTRAN - that all runs on the VAX. It's a thin client all the way. The code itself does nothing fancy with sending certain special commands that you can use with a VT terminal (depending on it's model). The entire point of maintaining the console interface is for not harassing the existing users. If it's not broke, don't fix it sort of thing. I will glance at your references. Thanks.
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
-
So, I have a system I am pitching to migrate to something modern. It was written in the early 80s using a VT terminal interface to a VAX. The customer has attempted to redevelop, migrate, re do this system about a 1/2 dozen times, all ending in failure. What keeps getting miss is that, at the end of the day, the system works. Production knows how to rapidly enter jobs to produce the product. So, picture a UI that is a series of terminal input. I guess the closest analogy would be entering prompts at the command prompt level. I really don't want to continue in this direction, but the UI is key to the effectiveness of the system. Unlike Microsoft, I abhor screwing with users. It's important that phase 1 of the new project look and behave exactly like the existing system. Any suggestions for libraries or toolkits. I don't care if I have to buy a license. The UI is the most evident thing about this application. There are users that are simply wizards at flying through the terminal based interface. I also have to migrate from flat files to an RDB and replace all of the report code with a modern report writer but that's another issue.
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
When replacing an optimized front end treasury system, I used but two hacks: 1. understand what information they need most and why and put it where they find it and 2. learn all of their keyboard shortcuts and replicate them in the new system. I can't overstate the importance of the ability of the operator to quickly enter all the data with just tab, alphanumerical characters and cursor keys.