[Interest] Guide me through the Qt offerings for GUIs

[Roland Hughes]

On 4/22/2021 2:06 PM, Rui Oliveira wrote:
> In my particular case (and it's not unique to me at all), I have a
> series of devices that I'd like to support, which have completely
> different and unrelated controls. This might be my "stuck mindset"
> talking, but I've seen this problem solved as I explained: "bring your
> own controller", and yes, a widgets object and a "logic" object with
> pointers to each other.

It's not a stuck mindset it's an x86 mindset.

"Everything needs to be linked into one program."

Fugetaboudit

Everybody should have to take COBOL and CICS when getting there 
programming degree. Much like the Kevin Bacon game, everything in IT 
eventually boils down to a CICS transaction.

User launches CICS application. CICS engine throws screen up on terminal 
while actual application runs in a batch queue. User tippy-tap-types 
away at terminal. Eventually they hit one of the limited function keys 
like <ALT><PA1> or they hit the funky little enter key. Either a partial 
or full screen of data gets sent as a message on the CICS message queue 
for the batch job. Eventually batch job wakes up, reads message, does 
something with it. Maybe that something sends a different screen or 
additional data back to the terminal, maybe not.

The first thing you need to do is decide what type of message you are 
going to use?

1) Serialized CoA (Common Object Array) most common in embedded world.

2) JSON

3) XML

4) Roll Your Own

After that you need to write yourself, buy, or find a publish subscribe 
message queue. You also need to decide if the queue depth for each 
message type will be one or N. It may sound horrible, but a depth of one 
is very common.

This message queue runs as its own little daemon/process on the system.

As each piece of your application comes up it looks for this message 
queue via some known name or other method. They connect to it and 
subscribe to the messages they want to receive. Most will make you 
announce the messages you intend to broadcast.

Each device runs as its own process/daemon. Your UI runs as its own 
process/daemon. It also connects to the message queue. There is no 
business logic in the UI. There is none of the "glue" layer stuff others 
have been chatting about. If it needs data in certain columns and sorted 
order it sends a CoA message asking a service for it. *If* a service is 
subscribed it will assemble the data as requested and publish a 
different CoA message.

You **always** publish without wait. Absolutely nothing waits for a 
response. Maybe something has already subscribed to your message, maybe 
it hasn't. You issue the request and cease to care at that point. If you 
are working in a SAFETY environment you publish the message and launch a 
timer that will trigger some kind of error log/indicator if a response 
is not marked as received within a certain window. You **never** 
actually wait for the response.

Devices come, devices go. When a device connects it needs to publish 
"Hey I'm Here!" It may connect and publish before the UI is alive. When 
the UI connects the first message it publishes is "Sound Off!" telling 
all of the subscribing devices to say "Hey I'm here!"

Nobody cares if anybody actually listens.

This back of the matchbook architecture works for large scale business 
systems spread across multiple business class operating systems and 
architectures all the way down to tiny medical devices.

No matter how much people hate green screens, we will never get away 
from CICS. When you try to get away from it you create tragedy.

If it helps, think about it this way:

A happy successful robust application has a whole lot of processes that 
simply don't care. Like a musician playing a song in a room all by 
themselves, they don't need an audience. If they have an audience, 
great! If not they are still going to play.




-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com