GUI controls for instrumentation

[Lamont R. Peterson]

On Tuesday 28 March 2006 07:44am, Kenneth Porter wrote:
> --On Tuesday, March 28, 2006 1:03 AM -0700 "Lamont R. Peterson"
>
> <lamont at gurulabs.com> wrote:
> > For an instrumentation application, Java would be a HUGE mistake.
> >
> > For an instrumentation application, C++ is a very sane choice.  There are
> > lots  of benefits and lots and lots of libraries for all sorts of I/O,
> > control &  input cards/systems out there.
>
> You seem to presume that one must code the whole thing in one language as a
> monolithic application. I don't expect some of my deployments to have a
> display. It might be a little "brick" computer buried in a rack or inside
> some OEM factory equipment.

No, I don't make that assumption, though I see why it would appear that way.  
Thanks for catching it.

However, most times I have seen Instrumentation apps, they are coded in one 
language plus an embedded scripting language is included for automating or 
"linking" of controls, inputs & outputs.  At least, that's the way the 
commercial toolkits usually did things.

Of course, this might no longer be the case, as I really haven't seen or done 
anything with instrumentation packages in about 5 years or so.  Then again, 
in this kind of area, I'm sure most people are sticking with what works.  
It's a pretty well established field.

> I expect to code the "back end" that talks to the hardware in C++, because
> my vendors' expose their API's either as C++ or C, and because I will be
> exposing an API to my customers. But the front end is going to be separate
> and may be attached either as a linked application (ie. exe/dll or
> executable/so) or via TCP/IP, possibly local. There may even be multiple
> "heads", with some acting as remote monitors while others act as control
> panels.

Yes.  That was part of what I was thinking/trying to say.  Most such libraries 
are C++ or (less commonly over time) C.  That's another one of the reasons I 
recommended Qt.  The main reason being that the OP asked about portability.

> One reason I don't want a monolithic application is because it gives me the
> freedom to try different front-ends based on platform support for control
> libraries. I might have a web front-end using SVG, a local one with Qt, or
> perhaps something using Java for either.

Yup.   Keeping flexibility in the design is a good idea.

> I expect any control library will give me the common stuff like windows and
> radio buttons. It's the more esoteric stuff like oscopes, gauges, and knobs
> that I'm trying to nail down.

Ah.  Well, there are plenty of libraries out there.  I haven't looked, lately 
(like I said) at such widget sets, but I have seen (at least some of) them 
for Qt, too.

Thanks.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060328/936c7084/attachment-0002.bin