GUI controls for instrumentation
Lamont R. Peterson
lamont at gurulabs.com
Tue Mar 28 16:06:21 UTC 2006
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://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/936c7084/attachment.sig>
More information about the fedora-devel-list
mailing list