Best language for adding a GUI to a C++ software [closed] - c++

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I've written a C++ software that can be used from the comand line and that, obviously, can be compiled and executed in different platforms (Linux, Windows and Mac).
This software in particular is very simple, it just displays a menu in the command terminal with a few options, takes input files (.csv) acordingly, runs in a few seconds, and prints back output files (also .csv).
Now I would like to write a platform-independent GUI for it without changing my original source code.
Which is the best language? C++? Java? Does anybody have experience or recommendations on this?
Thank you very much!

You will always have to change some of your C++ source code, in particular because GUI toolkits are all event-driven so are based upon some event-loop (often provided by the toolkit library).
Alternatively, you might have the GUI be a separate program (starting your command-line thing), communicating with some form of IPC -often pipes- with the command line program, which you probably still would have to extend
I suggest to use Qt5, which is a cross-platform (Linux, Windows, MacOSX, Android, ....) graphical user interface framework library for C++. If possible, use a recent version of Qt and code in C++11 (since closures become very useful).
Another approach (which still would require architectural changes) might be to make your software become a specialized web server, by using some HTTP server library like libonion or Wt (or perhaps POCO); then the GUI would be any recent Web browser. You'll probably need some web coding skills (AJAX, Javascript, ...) and you'll better understand the relation between continuations and web browsing. (See also this & that).
If your software is running quickly enough (e.g. less than some fraction of a second) you could make its core processing be a callback function (or a Qt slot) of your GUI program. But you should not have a function running for more than a few tenths of a second (otherwise, the user interface won't be responsive enough), at least not in the main GUI thread. Otherwise, split the computation in several parts or slices (e.g. "idle processing" in GUI toolkits, with CPS & coroutines being a relevant concept) to be sure that the event loop is frequently (at least 5 or 10 times per second) restarted, or adopt a multi-threaded approach (with a compute thread outside of the GUI main thread), which brings painful synchronization issues (e.g. you'll use mutexes).
BTW, the good question is not the "best" language but to find a good-enough approach, library and framework.

If You know C++ try QT,
Or look for different cross-platform GUI solutions.

You could expose some RPC-like services, and have the front end query your C++ back end. This way you could code your UI in another language, or even expose it on a web interface.

If you know C++ well,using WxWidgets would be good option.

Related

Why dont people use C++ for GUI as much as the Console Application? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
So im currently learning C++ as my second language.. Moving over from C# because I feel like C++ is a good toolset to have.
Now I know the basics and what not so I decided to create my first application which would be a string & byte array encrypter.. Basically a application with a simple GUI a few buttons, textboxes etc etc..
So I started looking at some opensource projects for something like this and ALL the ones I found were made as a console application? And I just find this very weird because most of the C# projects that I look up are 90% made with a GUI and not console based.
Why do people use the console applications to create projects? Is there something I should know before wandering in further into this new language?
People do use C++ for writing GUIs - the browser you are currently viewing this in is almost certainly mostly written in C++, as are many other complex, high-performance, desktop applications. However, doing so is not easy. If you simply want to knock out line-of-business applications, where performance is not critical, languages like C# and Java are easier to use - this is exactly what they were designed for.
People write "console applications" (i.e. programs that don't have a complex user interface) because for many tasks you simply do not need a GUI. For example, a compiler or a database engine has no need for such a thing.
Standard C++ includes "console" output. It does not include any facilities for GUI. There are various reasons for this - most notably, that a lot of devices targeted by C++ developers don't have a screen, let alone a need for GUI.
This means that anything to do with GUI in C++ makes use of a third-party library or framework, that targets the particular platform (operating system, etc) or platforms of interest. A number of good quality libraries/frameworks exist, but they differ from each other. Some of them are multi-platform.
When the objective is to learn C++, there is little point in trying to write a GUI program. The student will spend more time learning about details of a specific GUI library than about C++ itself. Learning about a GUI library is fine, but doesn't help much with learning C++. And the learning will often only partly relevant when learning another GUI library or framework.
A student who has learned C++ (and, yes, that means writing console applications rather than GUI programs) will have a working knowledge of how code constructs (functions, type definitions, etc) fit together. From there, it is easier to understand the documentation for a GUI framework that is written for usage in C++ development - since the documentation for such frameworks normally ASSUMES a knowledge of C++, and extends from there.
Of course, this does mean that a student of C++ - if they need to develop a GUI - has to decide what GUI framework to use. And then there is the effort of learning it. But it is not necessary to relearn C++ whenever one chooses to learn/use a new GUI framework.
There are a lot of tasks for which a user interface is simply not needed, and C++ does not force (or drag) a developer into writing a user interface unless they need to. That allows attention to be focused on the "back end" of the program - the calculations it does, rather than how the results are displayed. And when a decent GUI is put on the front of that, the result is a better system - whether that GUI is written in C++ (using a relevant framework) or some other language (using techniques to communicate between code written in different languages). User experience is based both on the visual aspects of GUI and on how efficiently the back end supports that GUI (response times, robustness, handling or reporting back end errors, etc). A well-designed GUI with a poorly designed back end will not work as well for the user, regardless of what language is used. This type of thing is why a number of systems with user interface - web browsers, etc - ARE written in C or C++. While it is easier to write a pretty GUI using other languages, it is often more difficult to get the back end functionality working efficiently as well, and C or C++ are often better for that.
Why do people use the console applications to create projects?
Sometime we don't need a Graphic UI, one command with arguments is enough. GUI need more time for programming.
Is there something I should know before wandering in further into this new language?
C++ is not the best choice for GUI in my opinion. You need to think about your platform, Windows, Mac, Linux or Browser. There are other better choices like Java which provided good UI libs and thanks to the JVM for platform adapting. Browser(Web app) is another area which is amazing too, and yes Javascript is the King.

Best practice to write application core and gui separated? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Sorry if this sounds a bit newish. I am writing a cross-platform application to learn C++, which, if it turns out to work well, could help people. I would like it to be able to be used in two ways: by the designed GUI (may be using QT), or by command line for expert users who want to go beyond.
I would like to know how the communication between GUI application and the core should be made, since this is going to be open source and I want the code to be nice and clean.
Is there any commonly accepted way to do this?
There are a few approaches you could follow.
First write the CLI, then write the GUI as a standalone program that spawns the CLI version for all processing (via the system(), popen(), fork(), g_spawn(), CreateProcess() or similar calls). This may be a little more tedious than writing a library, but works well if you have already written the CLI, or in cases such as batch processing where the GUI is just a fancy form where you choose the parameters.
Split the application not into two, but three parts: library, GUI and CLI. The library would contain all the shared logic between GUI and CLI, such as handling input formats, editing operations, and so on. The GUI part would implement the graphical interface using the functions from the library, and the CLI would implement the command-line interface using the same library.
Make the GUI application accept command-line parameters, and avoid initializing the widget library if the passed parameters indicate that it is invoked in CLI mode. This is OK for a primarily graphical application such as a bitmap editor or a programming IDE that needs to expose some operations for scripting. Note that some extra hacking is required to make this work on Windows, see this answer. Also note that this will make it harder to run the app on servers that don't have a windowing system, since it will still have GUI libraries linked in.

C++ Backend Infrastructure [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We have very complex C++ image processing engine, using Intel Compiler, OpenCV, etc.
Currently it is being integrated in our production via C# interop layer, which is so thin, it almost doesn't affect speed performance (and we are talking about few milliseconds per request). Now we are planning to migrate our systems to CentOS (and still support Windows platforms). Historically I don't have much trust in Mono, JNI also has its issues so most logical solution is to move towards pure C++ implementation.
Is it good idea in your opinion, considering we need to port following functionality:
1) Filesystem
2) JSON
3) Threads
4) Storm / Kafka / RabbitMq
5) XML
6) Log2Cxx
By the way I thought maybe about Qt, we don't need UI, but it will cover for us Filesystem, Threads, XML and maybe even JSON.
Many thanks,
Pavel
There's a very high chance that your credit card payment was processed at by a system that runs Qt core, so you're on the right track.
Qt is modular. You need a couple of modules that exclude the GUI stuff, although even GUI is usable in a server. It's pretty damn easy to paint some images to send back to the client, for example. I would recommend to use Qt whenever possible and only fall back on Boost if Qt doesn't provide what you need and it can't be implemented in a simple fashion. If you'll be undecided between Qt and boost, you'll end up with a lot of glue code that will make the whole thing much more work than necessary.
Qt doesn't have a logging mechanism per se, it has some facilities for debug output, but it needs more if you want real logging. It does cover the file system, json, threading, networking, communication between objects using event queues and/or signal-slot connections. It also has streaming XML parsers. You can integrate your project with log2xx. The durable messaging infrastructure will also need to be integrated since Qt doesn't provide that. You may find out that it's easier to implement just what you need, as far as messaging is concerned.
Asking about speed overhead of threading is a bit pointless, since in almost any framework out there, a thread controller is just a means of starting user code in a thread. It no runtime overhead once a thread is created. Everything depends on what code you run in the thread.
What you want to ask about, thus, is what code would you normally "run" in a thread? Ideally, you want only to run the event loop provided in the default implementation of QThread. The event loop synchronizes with other threads only when you're posting messages to it from other threads. That's what any other implementation of inter-thread communications would do anyway, so there's no extra Qt-specific overhead. You then move QObjects into the thread that is to run them (or simply create in code that runs in that thread already).
When you have to encapsulate blocking third-party code, like the notorious blocking database interfaces, then you'll be forced to put every database connection in its own thread. This would be the case whether you use Qt or not, so nothing special there.
Qt's XML and json implementations are reasonable, I don't see why they'd be much worse than anything else out there.
If you're serious about your project, you'll become a customer of Digia. I'm sure they'll answer your questions about what level of support is provided, about the stability, etc.
One benefit of using Qt for your project is that it's cross platform: you can run it on Linux or Windows servers. If it's a system for installation by third parties, this may be an important consideration.
Qt might also cover Log2Cxx since it has a logging mechanism. You can certainly parse JSON as far as I know on Qt 5.0. QJson is another alternative, you can check out:
http://qjson.sourceforge.net/usage/
Beside Qt, I would recommend Boost library for it is the first library that I would use in C++ when necessary.

C++ Core Application Development framework , Open Source , Cross Platform [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Like Qt , do we have any core application development framework in c++.
I think the qt is mainly for GUI applications . I need something other than QT , which gives a much faster running code ...
Visual Studio for c++ is a good choice , but its not an open source and cross platform one ..
To put it bluntly, to me it sounds like you're wasting your time and do not have clearly defined goal for your application. No framework can fix this problem. Write down application specification, list of target platform, check what functionality is required but missing, search for existing libraries, then use them.
I think the qt is mainly for GUI applications
You're mistaken.
In Qt 4 GUI component is optional. You are free to design console applications using QCoreApplication instead of QApplication for application object. As a bonus you get access to some GUI-related classes (not all of them, though - many require QApplication).
which gives a much faster running code
Making code run fast is your responsibility. If it runs slowly, then it is your fault until proven otherwise. Qt 4 is very fast, at least as far as GUI performance is concerned. Poor selection of algorithms, abuse of memory allocation routines and many other things can negatively impact performance. Switching to different framework won't fix those. Instead of searching for different tool, profile your code, search for bottlenecks and fix them.
Visual Studio for c++ is a good choice
It is not cross-platform. It is also not a framework - only IDE+compiler.
Cross Platform
Depending on your application you could even develop cross-platform application in standard C++ without any frameworks while using CMake/Scons/Autotools for build process. Unix-like environments have POSIX standard they more or less attempt to conform to, which can be used (on windows it requires cygwin/msys to be functional). Aside from that there's Boost. You could even ditch C++ and switch to scripted language to ensure portability. It all depends n your goals. Since you haven't said what you're writing it isn't possible to recommend anything specific aside from Boost. In addition to boost there are several frameworks (wxWidgets, Fox Toolkit, GTK) that may or may not meet your requirements.
Since it is not exacly clear what you mean by framework you might want to clarify that a bit more. Anyways, I am a happy user of boost as libraries for generic functionality and use eclipse + cdt as IDE to do coding and debugging. Boost, eclipse and the cdt are open source and cross-platform.
Which features should have the framework? How about the BOOST? It's not a framework as QT and wxWidgets, but it has a lot of features like delegates aka signals, threads, inter-process communications, network, etc.

minimal cross-platform gui lib? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm looking for a minimal and easy to learn C or C++ cross platform gui library.
In a nutshell I only need the following functionality:
application window
menu bar
some simple dialogs, File-open and save. Maybe a user-written one.
user canvas where I can draw lines an circles on.
some kind of message/event loop mechanism.
Target platforms would be Win32 and linux. MacOS would be nice to have but is not important at the moment.
Why am I looking for something minimal? I don't want to spend much time to learn a big and full blown abstraction system for a really small application. The easier and leaner, the better.
Any suggestions?
If you need something small, try FLTK libs: I used them at work (embedded development) and I think it's a valid option. Maybe apps are not as "cool" as QT-based ones, but developing with FLTK libs is fast and easy.
I don't know about minimal, but Qt is pretty easy to learn.
Its light-weight enough to run on embedded devices, so you be the judge.
EDIT after seeing the comments:
Yes, Qt is a fullblown application framework, but here's my case: an app with cross platform GUI but other platform-dependent code is not really platform independent. I don't think moving existing C++ code into Qt entails any work at all. If anything, this would allow Nils to use his existing C++ code, and only use Qt for a GUI. But of course, I assume that the existing C++ code is portable.
wxWidgets (formerly wxWindows) is a widget toolkit for creating graphical user interfaces (GUIs) for cross-platform applications. wxWidgets enables a program's GUI code to compile and run on several computer platforms with minimal or no code changes. It covers systems such as Microsoft Windows, Mac OS X, Linux/Unix (X11, Motif, and GTK+), OpenVMS, OS/2 and AmigaOS. A version for embedded systems is under development.
http://www.wxwidgets.org/
See Good C++ GUI library for Windows for relevant answers.
Personally, I would go with Qt, now that it's open. You don't necessarily want a minimal library, you want one that is easy to use, and quality documentation and community support will give you just that.
Small projects have the nasty habit of sticking around and picking up scope -- as things get hairier, you don't want to be stuck with some small library that nobody knows about.