Application GUI as Embedded Interface

[codeboy2k]

I ask because that kind of thing always used to be a pain with C/C++.

C++ namespaces have helped a lot these days.

I've used both Qt4 and Qt5 with Boost and ZeroMQ (C++), log4cpp, Xerces, and other libraries with no interaction problems.

The biggest problem I had with all these was building them all from source for multiple platforms and multiple older and newest GCC's. There was always something that was not portable or written in a way that caused that specific library to not build on the platform or GCC version that I needed.  And often these libraries depend on other libraries, that they pull in, usually C libraries, and these also needed to be compiled for the same GCC release(s).

So I ended up building and cloning several VirtualBox drives with appropriate OS releases and GCC versions and building (and porting the code, if needed) each library I needed for that platform.  And this included doing ALL of this on Windows XP, and Windows 7, Linux (Ubuntu) and OS X 10.7, 10.8 and 10.9.

That was a hassle, but it was not Qt's fault. It was just the regular library and source code incompatibilities that come from different build systems and versions.  I worked it through, but it was several weeks to get everything built.

[tggzzz]

I ask because that kind of thing always used to be a pain with C/C++.

C++ namespaces have helped a lot these days.

I've used both Qt4 and Qt5 with Boost and ZeroMQ (C++), log4cpp, Xerces, and other libraries with no interaction problems.

The biggest problem I had with all these was building them all from source for multiple platforms and multiple older and newest GCC's. There was always something that was not portable or written in a way that caused that specific library to not build on the platform or GCC version that I needed.  And often these libraries depend on other libraries, that they pull in, usually C libraries, and these also needed to be compiled for the same GCC release(s).

So I ended up building and cloning several VirtualBox drives with appropriate OS releases and GCC versions and building (and porting the code, if needed) each library I needed for that platform.  And this included doing ALL of this on Windows XP, and Windows 7, Linux (Ubuntu) and OS X 10.7, 10.8 and 10.9.

That was a hassle, but it was not Qt's fault. It was just the regular library and source code incompatibilities that come from different build systems and versions.  I worked it through, but it was several weeks to get everything built.

That sounds like a great way to be completely unproductive Other languages/environments have their problems too, but the issues you mention seem to be painfully self-inflicted (self=C/C++, not you personally!).

I'm sure it isn't Qt's fault, but it does rather illustrate how C/C++ might (or might not) be a little bit faster at runtime, but it does illustrate the problems with using C/C++ for prototypes and one-offs.

[codeboy2k]

It was totally version related.  I needed to build the software in each build environment in 3 versions of each of 3 OSes, 2 Qt versions, 2 boost versions, etc.. Each of these libraries pulled in more libraries that needed to be build, as well as needed things like Perl, Python, CMake, etc.. on each platform for building the code.  Often times the latest release would not build on older platforms, so I had to find the older releases, then these had to pull in a working older make or cmake or perl, etc....  It really was a versioning hell, that took about 3 weeks to get every build platform up and running.

I wouldn't call it non-productive. I don't consider productivity is only measured in coding time, but it certainly was tedious work.  Once it was done, software development and maintenance was a breeze on each platform after that.

Also, I don't think this is the fault of the language (C or C++) because the same thing can happen in any language. New versions don't compile on older tools, older libraries can't be found online anymore, or they don't build with newer tools, and need to be ported, stuff like that.

It was no joy, that's for sure   but once it was all built, the many libraries interoperated just fine on all the platform flavours and versions.

[nctnico]

I ask because that kind of thing always used to be a pain with C/C++.

C++ namespaces have helped a lot these days.

I've used both Qt4 and Qt5 with Boost and ZeroMQ (C++), log4cpp, Xerces, and other libraries with no interaction problems.

The biggest problem I had with all these was building them all from source for multiple platforms and multiple older and newest GCC's. There was always something that was not portable or written in a way that caused that specific library to not build on the platform or GCC version that I
That was a hassle, but it was not Qt's fault. It was just the regular library and source code incompatibilities that come from different build systems and versions.  I worked it through, but it was several weeks to get everything built.

That sounds like a great way to be completely unproductive Other languages/environments have their problems too, but the issues you mention seem to be painfully self-inflicted (self=C/C++, not you personally!).

I'm sure it isn't Qt's fault, but it does rather illustrate how C/C++ might (or might not) be a little bit faster at runtime, but it does illustrate the problems with using C/C++ for prototypes and one-offs.

I know you want C/C++ to be the axis of all evil but the problem Codeboy2k describes is due to programmers not wanting to keep their libraries and software backwards compatible. Worse, some build scripts depend on certain versions of Python, TCL, etc as well so a newer version of those scripting languages could also cause a build to fail. These are logistic problems and have nothing to do with C/C++. A new version of Python could break existing scripts just as easely.

[tggzzz]

I ask because that kind of thing always used to be a pain with C/C++.

C++ namespaces have helped a lot these days.

I've used both Qt4 and Qt5 with Boost and ZeroMQ (C++), log4cpp, Xerces, and other libraries with no interaction problems.

The biggest problem I had with all these was building them all from source for multiple platforms and multiple older and newest GCC's. There was always something that was not portable or written in a way that caused that specific library to not build on the platform or GCC version that I
That was a hassle, but it was not Qt's fault. It was just the regular library and source code incompatibilities that come from different build systems and versions.  I worked it through, but it was several weeks to get everything built.

That sounds like a great way to be completely unproductive Other languages/environments have their problems too, but the issues you mention seem to be painfully self-inflicted (self=C/C++, not you personally!).

I'm sure it isn't Qt's fault, but it does rather illustrate how C/C++ might (or might not) be a little bit faster at runtime, but it does illustrate the problems with using C/C++ for prototypes and one-offs.

I know you want C/C++ to be the axis of all evil but the problem Codeboy2k describes is due to programmers not wanting to keep their libraries and software backwards compatible. Worse, some build scripts depend on certain versions of Python, TCL, etc as well so a newer version of those scripting languages could also cause a build to fail. These are logistic problems and have nothing to do with C/C++. A new version of Python could break existing scripts just as easely.

1) Don't be silly. I don't "want" anything. I'm commenting on what is now the case.
2) Read my second sentence.
3) My second paragraph stands.

Your comments about other languages are true, but C/C++ exacerbates the problems.

[Fungus]

A new version of Python could break existing scripts just as easely.

And frequently does.

Getting Python/Tcl/Tk apps to work on a randomly chosen machine can be a nightmare. I've given up on a few occasions, it was just too much hassle.

Worse: It's the users that have to go through that, not the developers.

[dom0]

Your comments about other languages are true, but C/C++ exacerbates the problems.

Nope, dependency and build management is pretty much crap one way or another on almost any development platform. That's because it's a) a very hard problem to solve conclusively b) a big human factor, especially in release management.

[tggzzz]

Your comments about other languages are true, but C/C++ exacerbates the problems.

Nope, dependency and build management is pretty much crap one way or another on almost any development platform. That's because it's a) a very hard problem to solve conclusively b) a big human factor, especially in release management.

Not true for all languages. In particular many people have jumped on the "devops" bandwagon. There developers also take over part of the operations role so that you can "release early, release often".

I am familiar with situations in which code written by a medium-sized team is significantly refactored, then integrated with other large components (e.g. database), tested and released several times a day. There are o/s independent tools that make that trivially easy, notably "ant", "ivy", and (in an enterprise environment) "maven". Of course none of those work with C/C++, just as make doesn't work with Java.

The point is that the language made those tools possible, in a way that C/C++ simply doesn't and cannot.

[autobot]

One of the easiest ways to do so is to use python's "traitsUI" library:

Writing a graphical application for scientific programming using TraitsUI:
A step by step guide for a non-programmer

http://code.enthought.com/projects/traits/docs/html/tutorials/traits_ui_scientific_app.html

Also , there's enaml - which is the next generation of traitsUI:

https://news.ycombinator.com/item?id=9677375

[briselec]

Where I have little experience is in interfacing with PCs. I use both Windows and Linux, and don't really care which OS the solution comes under, though I suspect it may be easier in Linux. I really want to be able to quickly (and that's the key) whip up a GUI on my PC which can access some sort of hardware to communicate with a prototype board (be it through USB, serial port, even parallel -- the interface doesn't matter, as long as it's relatively easy to access, with or without OS libraries). I just want to be able to send information back and forth, for example click different buttons which send commands to the uC, which then sends data back to be displayed in a box. In my head this all seems so simple....

So why a GUI? You can do what you've described using programs like realterm or cutecom.

[B.B.Bubby]

Where I have little experience is in interfacing with PCs. I use both Windows and Linux, and don't really care which OS the solution comes under, though I suspect it may be easier in Linux. I really want to be able to quickly (and that's the key) whip up a GUI on my PC which can access some sort of hardware to communicate with a prototype board (be it through USB, serial port, even parallel -- the interface doesn't matter, as long as it's relatively easy to access, with or without OS libraries). I just want to be able to send information back and forth, for example click different buttons which send commands to the uC, which then sends data back to be displayed in a box. In my head this all seems so simple....

So why a GUI? You can do what you've described using programs like realterm or cutecom.

Or even terra term.  http://ttssh2.osdn.jp/manual/en/    comes with a Tektronix 4010 (4014) graphics terminal emulator.

[John Coloccia]

FWIW, my go to prototype GUI builder has always been Visual Basic. I don't know why anyone would screw around with Qt for something like this unless you're trying to make it harder than it is.