On Tuesday 28 March 2006 07:44am, Kenneth Porter wrote: > --On Tuesday, March 28, 2006 1:03 AM -0700 "Lamont R. Peterson" > > <lamont@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409
Attachment:
pgpteXinnPBfB.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
