Application GUI as Embedded Interface - Page 1
Forum section: electronics / projects

author: MrAureliusR
author_rank: Unknown
timestamp: June 13, 2015, 07:03:48 am
content: Hey again everyone! I might be opening a can of worms here by asking for advice on the topic, but I really am at a crossroads and would love to hear everyone's feedback and experiences.I've been programming in C for years and years now -- I would say I'm at the 'advanced' level, but probably not 'guru'. I really love the language, I've done tons of projects with embedded microcontrollers and it's all been merry and great fun.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 toquickly(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, what I'm really wondering is, which language would suit this best? I know that these type of questions can really get the fanboys going (myself included, when it comes to C anyway) but I'm looking for honest answers. I've looked at C++, Java, and Python mostly, though there are libraries for building GUIs with C (FLTK, GTK+, QT, etc...) and most of those have interfaces for the above languages.The real kicker here is fairly rapid prototyping. I know that, for example, TI's Code Composer Studio comes with something called GUI Builder, which is supposed to do exactly this, and while it sounds appealing I'm not sure how standard it is, or if it's at all easy to use, though I might look more deeply into that. I know (or at least the fanboys have told me) that Python can be really great for quickly throwing together code and getting something working. I'm not a huge fan of Java, but honestly if it offers a good solution here I'd be willing to look at it.I'm basically going to commit to learning a whole new language. Naturally, I've sort of been leaning towards C++ as most of my IDEs will support C++ as well (especially GCC of course) but again, it could go either way -- I'd even stick with C if it'll do the job. I know that Python has a million and one libraries, so I was kinda hoping there would be both a GUI library and a UART or USB library... So, it boils down to:1) Quick and easy to prototype with2) Decent graphics library (though nothing too advanced)3) Easy access to the PC hardware, whatever port or protocol usedSo, I'm holding my breath, and waiting for the impending explosionReally curious to hear what people have to say!

author: jdraughn
author_rank: Regular Contributor
timestamp: June 13, 2015, 07:07:28 am
content: For me it would be C# using Microsoft Visual Studio Express, easy to access serial or network with tons of tutorials and example code - but it would be pretty much Windows only.

author: miguelvp
author_rank: Super Contributor
timestamp: June 13, 2015, 07:17:17 am
content: Visual Studio Express? why?Visual Studio Community is free and without the limitations of Express.https://www.visualstudio.com/vs-2015-product-editionsI didn't upgrade to the 2015 one, I'm still on the 2013 versionhttps://www.visualstudio.com/en-us/news/vs2013-community-vs.aspx

author: slateraptor
author_rank: Frequent Contributor
timestamp: June 13, 2015, 07:24:27 am
content: I feel like what you're trying to accomplish is what NI's LabView does fairly well. Of course, LabView is not cheap...but I didn't see cost as one of your design constraints either. It's not a "programming language" in the traditional sense.Disclaimer: IhateLabView with a bleeding passion, but it would be disservice on my part if I didn't acknowledge that when it comes to creating quick, usable GUI panels for interfacing with simple hardware, it does a pretty decent job.

author: tggzzz
author_rank: Super Contributor
timestamp: June 13, 2015, 08:04:15 am
content: It partly depends on what the GUI widgets are going to be. Virtually any toolchain is going to be able to have "button" and "LED" widgets built in. It becomes more interesting when you want more "specific" widgets - at that point you have decide whether or not you want/need to develop application-specific non-standard widgets (e.g. a realtime oscilloscope or logic/spectrum analyser display), or whether you are assembling "standard" widgets such as knobs and meters.If you are interested only in knobs, meters, graphs, LEDs, buttons, then choose whichever library has suitable widgets and glue them together in whatever language the library uses.If you are interested in developing application specific scope/LA/SA class widgets, then you will need to look at the extensibility of the library widgets, and understand whether the underlying abstractions can be re-used for your purposes.Now for the personal bias...In 1991-1994 I watched 2 experienced C developers build a pretty crappy GUI in C++. The spent most of that time (3 years!) fighting the language and compilers - even then they could have done it in 10% of the time using Smalltalk. (And yes, there are several contemporary HP and Tektronix instruments that use Smalltalk for their GUI).By comparison, in 1997 Java had been available for ~1 year. I was astounded at the range of and sophistication of commerciallyavailablelibraries - especially compared with those thatweren'tavailable in the 9 year old C++! For my first Java programs, I developed several more sophisticated GUIs within 6 months, on my own. A very significant difference.Of course, I wouldn't recommend Smalltalk nowadays, but neither would I recommend C++ for fast turn-around prototyping. Consider the language characteristics noted in the C++ FQA athttp://yosefk.com/c++fqa/(I'm fond of the "const correctness" section!). Those problems aren't particularly visible when doing embedded code, but they do hit you at the GUI level.If the GUIs are going to be on workstations and you need to control pixels in real time, consider Java + JavaFX.Otherwise you have a wide choice!

author: AndreasF
author_rank: Frequent Contributor
timestamp: June 13, 2015, 08:05:15 am
content: I agree with the C#/.NET Visual Studio Express/Community recommendations. Very easy to build some simple GUI's and to interface to a serial port.

author: Karel
author_rank: Super Contributor
timestamp: June 13, 2015, 08:29:30 am
content: You write that you use both Linux and windows. Consider Qt. It's much better than msvc/dotnet. And you will not shoot yourself in the foot by being locked-in on windows...To setup a programming environment for Qt is peace of cake and you don't need to download gigabytes of software.Also, documentation, support and programming examples are excellent.Long time ago, I started with MSVC++. Then I switched to GTK. Then I made the move to Qt. It's the best Toolkit so far.And Qt is not just a graphical toolkit.l It's a complete C++ framework that contains many usefull classes (including serial port).Good thing as well is that you can write C code in C++. No need to rewrite all your C-code.

author: dom0
author_rank: Super Contributor
timestamp: June 13, 2015, 09:05:26 am
content: For a C programmer Qt/C++ is probably a good choice, although you shouldn't make the mistake of thinking that C++ is "C with classes" (it isn't). Many people find it really likable, even C-diehards like Torvalds.I also enjoy Qt/Python very much, the bindings are superb and there are tons of useful libraries in the PyPI. In many instances it's quicker to develop with than with Qt/C++, however, naturally the integration of the individual tools (UI designer, code editor, ...) are not as tight as with a static language like C++. Also, deployment is a tad harder with Python, especially for Windows. OTOH there are good libraries for instrumentation, graphs and math available.Qt provides two separate UI toolkits, Widgets and Quick, the former is a classic toolkit for desktop applications, the latter is based around a declarative language to rapidly create custom UIs (although you can do desktop apps just fine, too, but it's obviously not the main target of Quick) centered around touch and high performance on small devices.Quick requires 3D hardware, Widgets doesn't, you likely want Widgets for the desktop and Quick for e.g. Raspberry Pis or other SBCs you stuff into enclosures with a touch screen. Quick is really great for embedded apps, although you do notice sometimes that it's not as mature as Widgets, some things are not documented very well.I would advise against GTK, the Windows support (both from a technical and a community perspective) is very poor and the documentation is rather lacking.Java is neither a bad language (it's remarkably good given it's time of conception and designers, although they of course made some cardinal mistakes that bite you very hard in the ass sometimes) nor a bad framework per se, and it's very likable for backends, however none of the available UI toolkits deserves a "cross-plattform seal of approval". They just don't. They neither look nor feel like a native UI even at a superficial level, no matter what the toolkit promised you. Deployment can get nightmarish very quickly, although it works good in many cases. It requires a Java runtime (obviously) which many people don't have on their private computers anymore due to continuing security concerns.

author: Howardlong
author_rank: Super Contributor
timestamp: June 13, 2015, 10:22:21 am
content: I tend to agree that from a developer's perspective framework based languages like Java and C# may be popular, they aren't quite so popular with end users and IT operations because:O Prerequisites to deployment that can often conflict with other framework-based deploymentsO Very frequent and time consuming security updatesO Frameworks going out of supportO Why should an end user have to glue together a developer's software?Fortunately many Java deployments these days come with their own ring fenced Java runtime, but this is not universal, and it generally makes for a much larger download.Qt is OK, but make sure as a developer you have the exact toolchain available for maintenance, I have found that things frequently get deprecated and finding the right toolchain archive again can be difficult if not impossible.This is going to sound mad, but I still write basic UIs the Charles Petzold way in C using Win32 as I have done for over 25 years. The only problem I had recently with this was about three years ago when the dickheads at Microsoft made their C runtime break on Windows XP as the startup code called some Win API that didn't exist on that platform. At that time about 50% of the deployed base was Windows XP. They tried to make it sound like it was by design, but if that was the case it's even more retarded. Anyway they fixed it in a later service release.

author: nctnico
author_rank: Super Contributor
timestamp: June 13, 2015, 10:45:39 am
content: Quote from: Karel on June 13, 2015, 08:29:30 amDon't rule out wxWidgets which is Qt's open source competitor. Also based on C++ and it doesn't need you do distribute a runtime. I can e-mail the programs I make with wxWidgets because they are relatively small. If you are going into WxWidgets you'll really need to buy the book.

author: dom0
author_rank: Super Contributor
timestamp: June 13, 2015, 11:00:30 am
content: I once used Win32, too, but it's just a painfully cumbersome API, especially the newer ones introduced after XP. Basic stuff like layouts just takes lots and lots of code and well, yeah, that list just goes on. It's not like you can't do things, they just always require lots of code.Re. toolchains, yes, archiving them is always a good idea for large libraries.

author: Kalvin
author_rank: Super Contributor
timestamp: June 13, 2015, 11:01:17 am
content: Qt is very nice and productive environment for creating GUI based applications. Qt's framework provides excellent components for data manipulation and threads.Of course, one can create simple GUI apps with serial port support using plain Python. Python has tons of nice components available for data processing, like scipy and numpy.Qt has bindings also for Python, so combining the two, one can create extremely capable applications in a very short time.

author: diyaudio
author_rank: Frequent Contributor
timestamp: June 13, 2015, 11:10:57 am
content: Quote from: MrAureliusR on June 13, 2015, 07:03:48 amC# is probably the fastest to learn and prototype stuff for windows only (I personally have been doing lots of WPF stuff and its not easy but very polished compared to most frwameworks when done correctly), however as the guys here already pointed out, Qt is better for cross platform development, not sure how steep the learning curve is to get up to speed.

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 13, 2015, 01:32:50 pm
content: Quote from: dom0 on June 13, 2015, 11:00:30 amthats why you use MFC for it. just like Qt, wxWidget and whatnot, they encapsulate the hardcoded Win32 API you bothered so much.btw, i got a copy of wxWidgets manual book from the net sometime ago, can anyone suggest preferably a complete downloadable manual for the Qt? or upp? because those 3 are most talked about, i'm yet to decide which one to use and capable of minimal effort to build GUI and custom widget control/object... here are the list i checked last time...https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_librarieshttps://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments

author: Karel
author_rank: Super Contributor
timestamp: June 13, 2015, 02:14:13 pm
content: http://www.physik.uni-freiburg.de/~kernas/The%20Book%20of%20Qt%204%20-%20The%20Art%20of%20Building%20Qt%20Applications%20(No%20Starch%20Press,%202007).pdfhttp://www.bogotobogo.com/cplusplus/files/c-gui-programming-with-qt-4-2ndedition.pdfhttp://doc.qt.io/qt-5/gettingstartedqt.htmlhttp://doc.qt.io/qt-4.8/classes.htmlhttp://doc.qt.io/qt-5/classes.html

author: max_torque
author_rank: Super Contributor
timestamp: June 13, 2015, 04:46:54 pm
content: For really quick n dirty GUI stuff i use MS Excel! It has VB built in, and because it's a spreadsheet program at heart, handling data once you have it is easy. Super quick to prototype using it

author: dom0
author_rank: Super Contributor
timestamp: June 13, 2015, 06:00:24 pm
content: Quote from: Mechatrommer on June 13, 2015, 01:32:50 pmMFC is not much different from the Win32 API and not comparable to any of the modern frameworks mentioned in this thread...

author: miguelvp
author_rank: Super Contributor
timestamp: June 13, 2015, 06:14:48 pm
content: Quote from: dom0 on June 13, 2015, 06:00:24 pmFWIW, both Qt and wxWidgets are from the early 90's, MFC is from the same time. There is really nothing truly modern I prefer to call them all mature frameworks.

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 13, 2015, 06:22:17 pm
content: the only difference is MFC is Windows only, there is no #ifdef LINUX branch. and of course in very detailed implementation of them which is typical among (non-IEEE-standardized) brand names.

author: bson
author_rank: Unknown
timestamp: June 13, 2015, 07:11:25 pm
content: To just whip up quick programs, Python and Tkinter (https://docs.python.org/2/library/tkinter.html) makes this ridiculously quick and easy, and cross-platform. This can then be combined with numpy, scipy (for fft, filter generation, etc), sympy (to e.g. turn passive netlists into transfer functions), lambdas (e.g. functions that combine functions to build filters), python-ivi to interface with instruments (without littering your kernel with NI's flaky Visa support), matplotlib for plotting, and tons and tons of open-source code examples out there (including the runtime and all libraries themselves). Python has its problems, but functional prototyping is exactly what it shines at.

author: dom0
author_rank: Super Contributor
timestamp: June 13, 2015, 08:04:48 pm
content: Quote from: miguelvp on June 13, 2015, 06:14:48 pmThere where very major changes to Qt since Qt 1. MFC has been updated since then (I like to think of it as backporting of new APIs to MFC), but there were essentially no design changes. This makes a _huge_ difference.

author: nctnico
author_rank: Super Contributor
timestamp: June 13, 2015, 10:08:44 pm
content: IMHO the biggest problem with MFC is that Microsoft has dropped it about 20 years ago in favor of VB and when that didn't caught on C#. MFC is most definitely not the way to go. On the other hand there are several GUI design tools for Qt and WxWidgets which allow to create an application quickly.

author: John_ITIC
author_rank: Frequent Contributor
timestamp: June 13, 2015, 11:25:57 pm
content: Quote from: MrAureliusR on June 13, 2015, 07:03:48 amI have been reading the answers to your post. It appears you are an embedded developer that "needs" (not "wants") to develop a basic GUI on "some" OS to help stimulate your embedded system. The choice of GUI development tools entirely depends on your skills, the amount of investment in learning you want and the target OS and communication link used.For sending basic commands across a serial port you can use good old Visual Basic 5. There is very little learning curve. However, it is outdated technologies so you'll be learning "old stuff" that have little use in 2015.If you want to invest the time to do a "proper" GUI on Windows then I'd recommend C#/WinForms. This is fairly quick to learn and is very powerful even for professional GUIs. For a quick start, pick up Petzold's book on the subject (now $0.01 on Amazon.com):http://www.amazon.com/Programming-Microsoft%C2%AE-Windows%C2%AE-Developer-Reference/dp/0735621535/ref=sr_1_4?s=books&ie=UTF8&qid=1434237921&sr=1-4&keywords=programming+windows+forms

author: codeboy2k
author_rank: Super Contributor
timestamp: June 13, 2015, 11:35:42 pm
content: +1 more vote for Qt ...I've used both Qt and WxWidgets, and I prefer Qt. I find the entire Qt environment to be quite pleasant and easy to work in. There is a much larger community of Qt developers than Wx developers, and there is alot of helpful information out there and very decent online references and examples.There are Qt Classes for everything, and when you use their classes you really gain in portability. I've written software in Qt that runs on Windows, Linux and OS X without any problems, and uses networking, filesystems, fonts and graphics, timers, and message passing between different components. Across 3 different platforms the development interface is the same and quite literally ran on each platform with just a recompile.One forum member posted that you need to keep your toolchain used, this is so absolutely TRUE! You must keep the Qt libraries and gcc toolchain around if you ever want to build your application again, i.e. for maintenance fixes. Version changes of both the Qt libraries or the GCC compiler will often make an application not compile any more without far-reaching code changes. For maintenance, you never want to change code like this other than the bug fixes you need to implement. So yes, keep your libraries and toolchain squirreled away. I use a virtual box for this very purpose. Spin it up and I can build an older app again because it has everything I need to built that specific app on the virtual disk image.

author: fcb
author_rank: Super Contributor
timestamp: June 14, 2015, 12:05:36 am
content: I've developed a number of PC applications (for headless USB connected instruments) using PureBasic. I use Windows, but it will compile the application for Linux and Mac. Forum support is good and finished apps (including FFT's and scopes) seem to run very fast (I think it compiles down to assembler and is used by a number of games designers).www.purebasic.comPerhaps I'm a dinosaur - but I find basic far more simple to program, and really hate complex IDE's, toolchains etc...

author: miguelvp
author_rank: Super Contributor
timestamp: June 14, 2015, 02:11:55 am
content: Quote from: nctnico on June 13, 2015, 10:08:44 pmLast version I think it was 2013 (MFC 12), and I have not looked at what is new in 2015 yet but they do seem to give preference to the .Net framework using C# and I forget what other two languages but not C++. Maybe Java and Basic, or python?The current MFC (12) of course includes ribbons and all kinds of UI widgets Add some ActiveX components or what have you. I think it gives you more choices than the rest, unless you want your typical buttons and sliders and simple graphs.You can embed Videos via D2D very easily an offers more advance UIs, but of course at a price, and that price is that it has a steeper learning curve for the complex things.Other than that is trivial to make a compelling UI. But I'm not sure I would use it for an embedded device, or if it actually can be used that way at all.For IoT stuff sure but the GUI would be running on a PC not on the device.

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 14, 2015, 04:07:21 am
content: Quote from: miguelvp on June 14, 2015, 02:11:55 amembedded connectivity has nothing to do with GUI library. GUI library is just that, for building GUI. for embedded connectivity you need to include/install the device driver and dll/API, things like ftdi.dll etc and call that from your GUI.

author: MrAureliusR
author_rank: Unknown
timestamp: June 14, 2015, 06:05:42 am
content: It did indeed explode! But that's what I was looking for, a wide range of opinions and experience. First off, thanks again for being a wonderful community with great feedback and lots of info!To follow up on a few points, cost is indeed an issue -- I'm still doing my EE at school and money is, of course, tight. I'd rather use a free and open-source toolchain, not only to save money but to be able to submit bug reports, etc. I really enjoy feeding back into projects that I use and where the developers are nice.I've used GTK+ in Fedora a little bit before, though I found it hard to find documentation (in book form) about GTK+. It's a very interesting framework, they took C and basically tried to force OOP concepts up its rear end. It actually kind of worked! I liked the hierarchical structure, etc, but I did find initial setup a bit tedious.I'm hearing a fairly resounding tie between qt, Visual Basic/C#, and WxWidgets. I've only had a cursory glance at WX, and it looks pretty good. If I remember correctly, the version of Fedora I installed had a built-in IDE for it? Or is it an implementation of qt? I'm a little confused on that point, I'll have to Google it. I've heard a lot about qt -- that it's powerful, portable, and used in a lot of software on many OSes. The negatives I've heard are it can be a bit clunky and/or clumsy to use, but that was a while ago. I know that GTK+ is kind of halfway between two versions, and IIRC I think qt is as well? (not to mention Python! that's one of the few reasons I haven't dived into it yet -- which version should I use?!)And Visual Basic... or C#. I'm a bit wary of C#, not entirely sure why. I think because it's a Microsoft invention, (as is VB) and for some unvoiced ethical reason my mind kind of goes "Ew...". However, way back in Grade 10 I did use VB (version 5 I think?) and I do remember that it was easy to spin up GUIs quickly. I also remember (I think it was Mike from mikeselectricstuff) someone mentioning that they use it to spin up programs to access their boards with. Mike (if it was him) said he had to keep an antiquated version around as some of the support had been dropped and/or superceded with newer libraries or something? I also remember someone else saying that Turbo Pascal was the holy grail of these types of projects.To give a little more detail, I'd like to (depending on the project) have a small serial terminal, some buttons to turn things on and off, sliders, "LEDs" to show the state of pins, and some other widget to show A/D results. It would be nice to also have a few other bells and whistles like multiple windows and/or windows inside windows (whatever those are called these days, tabbed or not). I'd try and keep things basic because it's nice to be able to change things quickly without throwing out a ton of code. I think the easiest way to implement this would be to have a button click send a serial command which the micro then reads and carries out the associated task. These applications won't be going to any client any time soon, just for personal use and growth at this point. I'd also like to be able to tap into the PC's computing power now and then in order to crunch a bunch of numbers and then send the results back (though this isn't a requirement). I'd mostly like to just have something be quick and easy (though typically to have those two you need to spend money!).Thanks for all the input guys! Looks like I have a bunch more research to do. (If anyone can recommend good books that will definitely be a big plus for that solution. I like to have a book in my technical library for each language/framework that I use.)

author: MrAureliusR
author_rank: Unknown
timestamp: June 14, 2015, 08:19:17 am
content: Quote from: Karel on June 13, 2015, 08:29:30 amInstalling QT for Windows right now to give it a try and it says it'll take up 1.5GB or so when downloaded...

author: dom0
author_rank: Super Contributor
timestamp: June 14, 2015, 08:32:10 am
content: The MSVC, VS and SDK installation on my development Windows is (just checked) about 13 GB...edit: Just checked a Qt 5.3 install on Windows. Is about 2 GB (with all Qt modules installed for 'VC 13). As expected most of it are binaries (few hundred MB docs and examples), and most of that pertains to the PDB debugging files (about one GB alone). About 500 MB in Qtxxx.dll binaries, bute note that we're talking about Windows here, so you have everything twice (one debug binary, one release binary). Debugging binaries are 400 MB, so that leaves 100 MB for the actual release binaries.

author: Karel
author_rank: Super Contributor
timestamp: June 14, 2015, 08:53:34 am
content: Quote from: MrAureliusR on June 14, 2015, 08:19:17 amOne of the many reasons why we do all hard- and software development on Linux.

author: tggzzz
author_rank: Super Contributor
timestamp: June 14, 2015, 09:12:27 am
content: Quote from: MrAureliusR on June 14, 2015, 06:05:42 amAll that should be trivial in virtually any framework.An example of a modelling exercise I threw together in Java + Java Swing/JFC + JavaFX is shown below. I used those since they are free, have many many widgets, it is easy to combine widgets into composite panels, have excellent IDE (including GUI builders), and I was familiar with everything except JavaFX.The "CRT" is a custom JavaFX component, which I found easy to use - especially since the program expresses the X and Y coordinates in ns and V respectively, and I don't have to worry how many/few pixels are represented by each scope sample.But largely it will come down to whatever you are comfortable with, which libraries have the most useful widgets, and possibly which is easiest for extending with custom widgets.Have fun.

author: Karel
author_rank: Super Contributor
timestamp: June 14, 2015, 10:11:19 am
content: Quote from: dom0 on June 14, 2015, 08:32:10 amI never had to download such amount of data. But I don't use Qt Creator. I prefer to use Kate,one of the best editors for programmers.Simply enter the following commands:OpenSuse: zypper in libqt4-develUbuntu: sudo apt-get install libqt4-dev libqt4-core g++That's all you need to develop with Qt, no need to download gigabytes of software.Personally, I always compile Qt from source. This way I can configure it the way I want and remove all modules I don't need.This is what I do on OpenSuse:some prerequisites:zypper in gcc-c++ xorg-x11-devel cups-develDownload and unpack:http://download.qt.io/official_releases/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gzJust 230 MB!enter the following command to configure:./configure -prefix-install -release -static -fast -opensource -largefile -no-exceptions -no-accessibility -no-stl -no-qt3support -no-xmlpatterns -no-multimedia -no-audio-backend -no-phonon -no-phonon-backend -no-svg -no-webkit -no-javascript-jit -no-script -no-scripttools -no-declarative -no-declarative-debug -qt-zlib -qt-libtiff -qt-libpng -qt-libmng -qt-libjpeg -no-openssl -no-nis -cups -no-dbus -no-gtkstyle -no-nas-sound -no-opengl -no-openvg -nomake demos -nomake examples -nomake tools(I removed a lot of shit I never use)make -j12(takes only 5 minutes on a six-core AMD)sudo make installnow you can compile whatever Qt project.If you try to do this on windows, bring your sleepingbag...

author: Lukas
author_rank: Frequent Contributor
timestamp: June 14, 2015, 10:11:43 am
content: Others may disagree, but I've found GTK+ to be my preferred toolkit. It's got a straightforward API, documentation is good and has by far the best GUI designer (Glade). I use Gtk almost exclusively from python, since the GObject stuff requires way too much boilerplate.Unfortunately, support for other platforms than linux is lacking (there's code in gtk to support windows, but there are no builds) and there's nothing like qwt for easy data visualisation.

author: Xenon Photon
author_rank: Unknown
timestamp: June 14, 2015, 07:10:02 pm
content: C#.NET ftw!If I have the power to make everything programmed in one language I'll select C#, except for web servers PHP is better than ASP.

author: Kalvin
author_rank: Super Contributor
timestamp: June 14, 2015, 07:24:38 pm
content: Quote from: Xenon Photon on June 14, 2015, 07:10:02 pmI would brute-force Ada.

author: dom0
author_rank: Super Contributor
timestamp: June 14, 2015, 07:29:16 pm
content: PHP is probably the most horrid language of all languages conceived seriously (especiallyconsidering the date of, uhm, "invention"), it becomes barely bearable with a good framework and is complete and utter nonsense - widespread nonetheless, for 'simple' deployment (actually not wrong - for very simple sites deployment is very easy, but becomes very cumbersome and complicated for larger sites. The word unmanageable comes to mind...)

author: eneuro
author_rank: Super Contributor
timestamp: June 14, 2015, 07:49:51 pm
content: Quote from: MrAureliusR on June 13, 2015, 07:03:48 amUselibusbwith small dongles with small MPUs attached to PC USB porthttp://sourceforge.net/projects/libusb/files/Thare are Linux & Window$ versions of this library.As simple as it is and even small AVR Attiny85 can be used as MPU attached via USB, so you can whatever you want-use 2 MPU pins and have I2C via USB, or other registers and GPIOs available if you MPU of choice has small amount of pins, etc.I see no reason not to use C programming, while it is very easy check assembler output and optimize your code or add asm inline statements, etc.Messing with other higher level languages or... Arduino's...if you are good in C/C++ programming like me

author: codeboy2k
author_rank: Super Contributor
timestamp: June 14, 2015, 11:36:20 pm
content: Good notes @Karel for downloading and installing qt. However, you should be using qt5 now.I usually do the apt-get install just when I need qt4 or qt5, and I don't need anything special, but sometimes I need to use it with an older version of gcc, say 3.8, so then I need to build it from source, but it builds easily and you can strip what you don't need as shown.Qt is, in my opinion, the absolute best cross platform native app builder available. It truly is a cross-platform C++ framework with classes for threads, thread message passing, networking (servers/clients), application message passing (i.e. IPC), filesytem access, graphics, fonts and text, sql db,Youtube Channel VoidRealms has a long playlist of Qt tutorials herehttps://www.youtube.com/playlist?list=PL2D1942A4688E9D63He also has other programming tutorials, like Java, C# , C++, HTML, etc... but the Qt Tutorial is the most extensive and covers many of the Qt Framework classes.

author: MrAureliusR
author_rank: Unknown
timestamp: June 15, 2015, 01:35:19 am
content: The Python/TkInter method looks pretty appealing as well... I'm probably even more indecisive than before I posted this, now that I've got so many strong answers pulling in all directions!Again, if someone can recommend a good reference book on one of these solutions, that would be GREATLY appreciated!*sigh* sometimes, you get what you wish for!

author: tggzzz
author_rank: Super Contributor
timestamp: June 15, 2015, 07:29:25 am
content: Quote from: codeboy2k on June 14, 2015, 11:36:20 pmI find it surprising that a GUI framework needs to include those facilities - I would have expected that there were standard libraries for them. Do those facilties in QT "play nicely" with similar facilities in other libraries in an application that contains QT?I ask because that kind of thing always used to be a pain with C/C++.

author: nctnico
author_rank: Super Contributor
timestamp: June 15, 2015, 08:53:36 am
content: Quote from: tggzzz on June 15, 2015, 07:29:25 amCross platform is the keyword here and the GUI is just a small part of what a cross platform framework offers. Qt and wxWidgets provide convenient C++ classes which hide and smooth over the underlying OS and associated libraries idiosyncrasies. So even if you never use a different OS it may be benificial to use these frameworks.

author: Fungus
author_rank: Super Contributor
timestamp: June 15, 2015, 08:53:48 am
content: Quote from: tggzzz on June 15, 2015, 07:29:25 amQTisa standard library for those things.Quote from: tggzzz on June 15, 2015, 07:29:25 amYep.Quote from: tggzzz on June 15, 2015, 07:29:25 amThat's why they put them in QT.

author: Karel
author_rank: Super Contributor
timestamp: June 15, 2015, 09:02:17 am
content: Quote from: tggzzz on June 15, 2015, 07:29:25 amOne of the reasons Qt includes them, is to make it easier to do cross-platform development.The C and C++ standards don't include api descriptions for networking or serial ports.But the biggest problem is, there is the way microsoft does things and there's the way the rest of the world is doing things.Microsoft has always been (and still are) trying to be incompatibel as possible. Either by slowing down standardization, specially the kind that makescross-platform development easier, or by patents. Lockin is there businessmodel.Qt tries to overcome those burdens.

author: tggzzz
author_rank: Super Contributor
timestamp: June 15, 2015, 09:58:34 am
content: It appears I didn't make myself clear. The pain I was referring to was the difficulty of getting multiple libraries (each duplicating some features found in the others) to play nicely with each other without conflict.Sure, if an application only needsonelibrary, e.g. QT, then that isn't a problem.As for Fungus' statement "QTisa standard library for those things", I'd put the emphasis on "QT isastandard library for those things".

author: Fungus
author_rank: Super Contributor
timestamp: June 15, 2015, 10:03:10 am
content: Quote from: tggzzz on June 15, 2015, 09:58:34 amIf you're using QT for the GUI then it makes sense to use it for the serial ports as well (assuming it's up to the job).If it isn't, then... let's hope everybody involved knows about C++ namespaces.

author: dom0
author_rank: Super Contributor
timestamp: June 15, 2015, 10:29:33 am
content: Quote from: tggzzz on June 15, 2015, 09:58:34 amLibraries bringing their own string/list/vector implementations to the table (Qt does that, but they are designed so as to be compatible and convertible to std:: ) whichdon'tinterop with std:: will always be troublesome, although it has become less of an issue (library vendors don't do it that often anymore and it's easier with C++11+ to build bridges).Name clashes have never been an issue with C++, at least for me. With Qt not anyways, everything has a prefix (at least Q) and if necessary you can put Qt in a namespace.

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 15, 2015, 11:44:15 am
content: Quote from: nctnico on June 15, 2015, 08:53:36 am+1. those facilities are so typical in everyday real life Apps, with the current Windowed (not console) programming environment, they've became highly correlated with the GUI. leaving out those facilities to programmers to code OS specific API in their Apps seems to defeat the purpose of the cross platformness of it. perhaps GUI framework is misleading or not the right word for it. maybe we should call them OS API wrapper or simplifier or encapsulator. with exception to "hardware specific facilities" (drivers/API) i dont believe currently there is a single OS, API or class framework that can cover every hardwares/embedded systems on this world.

author: dom0
author_rank: Super Contributor
timestamp: June 15, 2015, 11:55:56 am
content: Quote from: Mechatrommer on June 15, 2015, 11:44:15 amThe term is "application framework".

author: codeboy2k
author_rank: Super Contributor
timestamp: June 15, 2015, 01:48:48 pm
content: Quote from: tggzzz on June 15, 2015, 07:29:25 amC++ 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.

author: tggzzz
author_rank: Super Contributor
timestamp: June 15, 2015, 02:45:49 pm
content: Quote from: codeboy2k on June 15, 2015, 01:48:48 pmThat sounds like a great way to be completely unproductiveOther 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.

author: codeboy2k
author_rank: Super Contributor
timestamp: June 15, 2015, 04:19:02 pm
content: 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 surebut once it was all built, the many libraries interoperated just fine on all the platform flavours and versions.

author: nctnico
author_rank: Super Contributor
timestamp: June 15, 2015, 04:20:27 pm
content: Quote from: tggzzz on June 15, 2015, 02:45:49 pmI 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.

author: tggzzz
author_rank: Super Contributor
timestamp: June 15, 2015, 04:46:55 pm
content: Quote from: nctnico on June 15, 2015, 04:20:27 pm1) 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.

author: Fungus
author_rank: Super Contributor
timestamp: June 15, 2015, 04:51:46 pm
content: Quote from: nctnico on June 15, 2015, 04:20:27 pmAnd 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 theusersthat have to go through that, not the developers.

author: dom0
author_rank: Super Contributor
timestamp: June 15, 2015, 05:19:06 pm
content: Quote from: tggzzz on June 15, 2015, 04:46:55 pmNope, 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.

author: tggzzz
author_rank: Super Contributor
timestamp: June 15, 2015, 08:06:09 pm
content: Quote from: dom0 on June 15, 2015, 05:19:06 pmNot 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.

author: autobot
author_rank: Regular Contributor
timestamp: July 02, 2015, 08:43:10 pm
content: 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-programmerhttp://code.enthought.com/projects/traits/docs/html/tutorials/traits_ui_scientific_app.htmlAlso , there's enaml - which is the next generation of traitsUI:https://news.ycombinator.com/item?id=9677375

author: briselec
author_rank: Regular Contributor
timestamp: July 03, 2015, 11:39:09 am
content: Quote from: MrAureliusR on June 13, 2015, 07:03:48 amSo why a GUI? You can do what you've described using programs like realterm or cutecom.

author: B.B.Bubby
author_rank: Regular Contributor
timestamp: July 03, 2015, 12:01:36 pm
content: Quote from: briselec on July 03, 2015, 11:39:09 amOr even terra term.http://ttssh2.osdn.jp/manual/en/comes with a Tektronix 4010 (4014) graphics terminal emulator.

author: John Coloccia
author_rank: Super Contributor
timestamp: July 03, 2015, 12:57:29 pm
content: 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.