On Thursday, May 14, 2020 at 9:42:58 PM UTC-7, jas wrote:

Back in 1994 When the World Wide Web was very new and long before it was discovered by more than a very small number of people, or generally available, one of our programmers (UC Davis VMTH ) wrote a MUMPS web server that ran on DTM and provided a web

based interface to our hospital information system that was also available to our users via VT-100 type terminals. Years later the system was converted to a different version of MUMPS that ran on Open Source Linux, GTM.

The web interface was much better for use by the doctors and students, but the CHUI interface was much better suited to the staff at that time. Both were very quick, unlike many GUI interfaces I have seen in doctors offices even today.

Later the web interface was extended to staff also, mostly as staff turned over and new users became less amenable to learning and using the old technology. After I retired, about 10 years ago, an effort was begun to replace the web interface with

something written in Java. This was driven by administration and outside technologists who had no idea what they were getting into. I have no idea if they have been successful.

Fortunately, the remaining technical staff were able to convince the administration not to waste their time trying to replace the MUMPS running the whole thing or they would have had a costly disaster with it long ago.

Web based interfaces to information systems do not have to be slow or poorly focused on productivity and efficiency. Although many are, or were, that was largely a result of incorporating too many images into application designs before internet speeds

and personal computers were ready to handle them quickly.

MUMPS was and continues to be technically well suited to rapid development and deployment of information systems large and small, although it is largely unknown now outside of the circles where it has found a special niche, such as large medical

information systems and international banking.

On Monday, April 20, 2020 at 11:49:23 AM UTC-7, retired developer wrote:

Hi,

I'm a little bit curious and ask you...

In those old days we all had displays, mostly VT-52 and then the
legendary VT-100 (with all the VT-100 compatibles) as the user
interface. By "old days" I mean some 40 years ago but at least one
company I know, still uses such a computer system this very days too.

...so the question is, are nowadays such displays (or emulators like SmarTerm220, Reflection, Powerterm and others) still in use?

Does somebody knows of (or uses) such character based user interfaces (which are today in use) or were all replaced by some kind of GUI or Web applications?
How was the transition from CHUI to GUI/Web - did the people just
adapted the old Apps or rewrote the whole application?

Regards,
J., the (retired) mumpster

--
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has another security holes.
For safety you must care yourself.

Thinking about building a loosely coupled GUI builder for M technology users. Think there is any interest?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04.08.21 23:02, Rick H wrote:

Thinking about building a loosely coupled GUI builder for M technology users. Think there is any interest?

Hello Rick,

what do you mean with "loosely coupled"?

Regards,
Julius

--
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, August 5, 2021 at 2:23:29 PM UTC-7, retired developer wrote:

On 04.08.21 23:02, Rick H wrote:

Thinking about building a loosely coupled GUI builder for M technology users. Think there is any interest?

Hello Rick,

what do you mean with "loosely coupled"?

Regards,
Julius
--
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

the code is external to any m executable. sort of like qt without the event q issues and all the libs.
communication is via tcp, so the gui engine can be on the same or one or more other computers.
...and it will present a lot faster than MWAPI.

Yes, we thought of com objects, etc. But, that, typically requires an M vendor-specific Z command.

write (W) commands to the gui engine; read 'events' posted by it and logically manage them however you want. Typically, execute the string that is returned.
use tcp1 w "button .b1 -text Continue -action {your mumps code goes here}

This is what we did with CACHE. 80 desktops managed by 4 Cache jobs. We got a pass from Intersystems with this form of implementation - not allowed by contract. But we brought them into American Airlines, so ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, August 5, 2021 at 2:23:29 PM UTC-7, retired developer wrote:

On 04.08.21 23:02, Rick H wrote:

Thinking about building a loosely coupled GUI builder for M technology users. Think there is any interest?

Hello Rick,

what do you mean with "loosely coupled"?

Regards,
Julius
--
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

No. MWAPI is way to slow...and understandably so. And it does not provide for the construction of alternative form of window management. The solution will leverage the technology of tcl\tk (what's that?), and will work in very much the same way as qt -
but without the need to link to an event que or loads of libraries.
Asking who uses tcl\tk is like asking who uses mumps -
Well the medical community is steeped in M tech; and those little guys now moving around Mars, and the guidance system that help get them there .... tcl\tk.
Anyone with more than half a brain would be using tcl\tk instead of python. No apologies.

The CCSM implementation, though never stable, is an example of 'a' way that I think is better, faster and less complex.

The free \donor version would provide for the construction and execution of a GUI as a give back to the community.
Addition of speech recognition; text to speech and multimedia - audio, video - fee.

The solution is not a wet dream; it has been commercialized. examples on verbaltransactions.com

Here is an example of two buttons on a toplevel form. Note that in this instance, the controls take on the visual characteristics of the users Win 10 window theme.
# instantiate a form
write ".toplevel .myform -width 80% -height 50% -title {Button Selection}
# instantiate two controls
write "button .myform.b1 -text Continue -state normal -action {some mumps code that is invoked when button is selected}
write "button .myform.b2 -text Ok -state disabled -action {some mumps code that is invoked when button is selected}
# present in any of three forms of window management
# pack -
write "pack .myform.b1 -side left"
write "pack ..myformb2 -side right"
# grid -
write "grid .myform.b1 .myform.b2"
# place -
write "place .myform.b1 -xpos 20points -ypos 40points"
write "place .myform.b2 xpos 80 points -ypos 40points"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)