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 2 years ago.
Improve this question
I'm trying to write a program that can read from a bunch of sensors, make decisions on a windows computer, then write to some actuators (e.g. valves). This is all already done on an existing system and program but we want to do something different and so are starting with a new program on the windows computer from scratch.
The reading and writing of sensors etc is done through a custom-made PCI from the manufacturer and basically I'm not sure how to read and write to the registers on the board. I've done projects with Raspberry Pis and other microcontroller+PCBs but this one's a bit new. The original program was written in c++ if that helps.
Any general or specific info on interfacing directly with PCIs from windows systems would be great, and if this isn't enough info let me know and I'll provide more. Thank you!
You need to access the hardware via a driver provided by the manufacturer. Many manufacturers don't document how to access their drivers directly by the end user code. Instead, they provide an API library (in an SDK) that the users call into to operate the PCI device.
It'd help if you'd post a link to the device you're using - that way we could look at what's bundled with it and help you decide whether it's worth the effort. If the manufacturer is non-cooperative, this may be a relatively hard thing to do. You may have more luck not using the PCI card and e.g. getting some EtherCAT I/O modules, using an open source EtherCAT master library, and connecting your application to the I/O modules via a simple network card. That would be way more supportable, and very resistant against obsolescence, as the EtherCAT I/O is not going away anytime soon, and your code could be fully portable if you used a portable app development framework like Qt or wxWidgets. You could then run it on PCs, macs, Raspberry PI - and it'd do the same thing and look mostly the same. It's not a pipe dream - I maintain some code that does pretty much just that and it's a viable approach. As long as your requirements are "soft" realtime, it's bound to work. If you need hard-realtime, you'll need to limit yourself to Linux with realtime extensions, and access the network interface (using the ECAT master library) from a realtime thread. It's still more developer-friendly than, say, using a PLC with EtherCAT Master support - those usually use CODESYS under the covers, and that's basically just spreading misery :(
In my experience, supporting some custom motion-control PCI cards and such ends up being semi-rewarding, since you get to do some reverse engineering all too often, and that's a good challenge, but it's a dead-end ultimately. If the card has no API/SDK available, then it's best assumed that the manufacturer is dumping it, and all your work will be for nothing when it goes out of support or becomes unobtainium. It's best to rely on viable industry standards, and on interfaces that have multiple vendors on equal footing. EtherCAT I/O is dime a dozen, almost. You can use e.g. the (freely downloadable) TwinCAT to explore the I/O module's functionality and prototype stuff, and then implement it in your own code using the ECAT master library, perhaps with help of WireShark when needed.
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.
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.
I'm writing a distributed system wherein each node interfaces with local applications via some RESTful API, supports extensions and runtime customization, etc. It's a bit like an Enterprise Service Bus over the wide area, but with a lot else going on which is not related to the question at hand.
I've read a little about both MPI and Asio - originally I was set on Asio, but then I found MPI, and now again I'm thinking Asio is the better solution for me. MPI seems to provide a lot I don't need and a higher level of abstraction than I want - for example, I only need point-to-point communication, and it is important to me to be in control of when and what data is transmitted. (e.g. I have already designed a packet structure that I would conform to ideally)
So my primary question: it is worth it to start from a lower level with Asio, or should I try to graft MPI onto what i'm looking for? Further, are there 'skeleton applications' available which use MPI or Asio which would aid development? (Actually I am 100% new to C++.. ;) Or, does it make sense to use them in tandem?
For more perspective, maybe it's worth noting that I already have implemented the bulk of this project in Perl using Perl Object Environment, which itself is just an asynchronous event system with a ton of networking libraries.
Also, if it makes a difference, I would ideally use threads for this.
Honestly though I have not used Boost at all yet, as I hinted above, so any input is appreciated.
I should start by saying that I know nothing about Asio, but from the 2 minute scan of the website and the description of your problem, it sounds like while either would probably work for you, Asio might be simpler. MPI is really designed less for general purpose network communication and more for running applications where the set of processes and applications is a little more static. While it provides a client/server style interface if desired, it's not the main focus of the library.
MPI is also more difficult to use if you already have a packet structure designed. MPI is great for abstracting away the need to worry about packets, location of processes, etc. but if you've already taken all of that into account in you application, you have already done the hard work.
There have been at least one other discussion of Asio vs. MPI that you can take a look at (For distributed applications, which to use, ASIO vs. MPI?) to get more opinions too.
I have a large cross-platform (Linux and Windows) C++ project, for which I want to create a GUI.
I have few very general questions about the basic principles of GUI for such project:
Should the GUI be separated from the application's logic?
If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
Is it a good idea to have a browser-based GUI?
Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
Should the GUI be separated from the application's logic?
Yes, definitely....
If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
...but not that much. Sockets would be overkill (exception: see question 5). Usually you split up the classes in GUI and backend parts. The GUI classes then call methods of the backend.
Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
If so, you would have to integrate the two languages, so I would recommend writing everything in the same language. But to answer your question, you could for example create Python bindings for your backend and write the GUI in Python (with PyGTK, PyQT or wxWidgets).
Is it a good idea to have a browser-based GUI?
That depends on how you want to deploy your application. If it should be installed on each client computer, a web interface doesn't make sense. If you want to host it centrally, then you might opt for a web interface.
Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
I think this makes sense only if the backend must be some kind of secure (i.e. must not be installed on users' computers) or if you have a thin client-like approach as in question 4. Writing cross-platform GUIs is much easier than writing cross-platform backends (in my opinion), so you should rather do both parts cross-platform. By the way, .NET-based GUIs are not Windows-only - Mono already supports a great subset of Windows Forms, for example (but not WPF, sadly).
EDIT:
Concerning your Mono question: Mono is mostly stable, but not everything is yet implemented. To be sure, you can run The Mono Migration Analyzer (MoMA) to find out if something will not work in Mono. But I think the fact that so many companies are successfully using Mono in production environments means that you should at least consider Mono as an option!
Should the GUI be separated from the application's logic?
It should, because the UI widgets are just types of objects and one of the rules of OO says that each
object should be trusted with the responsabilities that it can fulfill. A dialog doesn't know much about
serialization for example.
If it is separated, how should the logic and the GUI communicate? Are
TCP/IP sockets a good option? What are
other possibilities?
It depends on how much separation you need. I use asynchronous messages for communication, and then I can use
different transport layers without many changes.
TCP/IP would allow you to use the GUI on a separate machine from the core, but it has higher overhead than
passing around window messages for example.
Is it a good idea to have the GUI in a
language different than a C++? If yes
- which language?
Ideally, you should use as few languages as possible unless you really need the technical capabilities of a
certain language. GUIs are more of a library problem than a language problem, so if you can find a very good
C++ UI library (hint: Qt), you should code all your program in C++.
Is it a good idea to have a
browser-based GUI?
It could be, but you should think about requirements and not ideas. Do your customers want to interact with
your program from a browser? Can they afford the extra costs and development time? Do you have the know-how?
Even though the project's core logic
is cross-platform, I can decide that
the GUI will be only Windows-based
(.NET?) and it will communicate with
the logic on the relevant Win/Linux
machine through Socket or similar
method. Is it a good idea to do so?
It could be a good idea, but see the answer to #3. Also consider that you're going to work on a client-server program, which is significantly more complicated than a stand-alone program.
Finally, you need to examine the pros and cons of a .NET dependency over using a C++ UI library: what .NET brings you that you couldn't get with wxWdigets, Qt, gtkmm, etc.
(1) Usually yes, this makes it possible to maintain the business logic and the user interface separately. It also enables you later to have e.g. both a browser-based SaaS user interface as well as a desktop-style local networkless operation mode and still share the whole application logic code.
(2) Not using TCP/IP sockets. Typically the application and the GUI would communicate using event and/or message passing. For example, when the application wants to notify the GUI that something happens, it creates a synthetic event that is then pushed to the event queue of the GUI. If the application is event-based also, the GUI can communicate with it by posting events. For non-blocking, quick operations the GUI can call the application logic code directly, but then the call must be guaranteed to return quickly. For slower operations, you need a separate thread anyway to process them. This thread can be the one that processes the application-side events, or you can spawn it as a worker thread when needed.
Our company's product has a user interface on top of Eclipse IDE, but part of the application logic is written in C++. The two parts communicate over CORBA, i.e. basically asynchronous event mechanism. We have been happy with this solution.
On a smaller scale, GUI applications typically separate UI and application logic using abstractions such as Model-View-Controller (MVC).
(3) It's always a hassle to integrate components written in two different components. I think you should to that only if you have an obvious platform benefit. E.g. we benefit from the Eclipse IDE components, whereas the application benefits from the raw speed of C++.
(4) Browser-based GUIs are great, but the integration with the business logic suffers from latency and the stateless mode of web servers makes the architecture cumbersome if you actually have a desktop-style application. A browser-based GUI is good for software-as-a-service applications because they don't require installation by the user and can be upgraded by the product developer at will, but if you don't plan to offer your product as a software-as-a-service product (a la e.g. Salesforce).
(5) If your application logic is cross-platform, I would try to strive to make the UI cross-platform also. Otherwise for those platforms where you only support the application logic you may need to install two operating systems, one to run the UI and one to run the application logic. There are good cross-platform user interface frameworks, at least
AJAX / browser-based UI
Trolltech/Nokia Qt
Eclipse (SWT)
Java Swing (hmm...)
it is better to use python as your base gui language with QT as gui platform.
if you split gui and base program in separate processes then you can use this mechanisms for communication:
signals and slots from Qt
subprocess module at python
local sockets.
use files [write configs to file and signal other process to refresh]
but it is better to create one process and call your base language directly from python and communicate with native language's data structures. you cat use swig for this purpose. but because you can't call python functions from within C++ you can use pooling at python for some changes in shared data and do something based on this changes. i experienced two way. when i used python for GUI and management, it can be very time saving.
1. Should the GUI be separated from the application's logic?
Yes. However, see answer #2
2. If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
I believe this is a best answered by choosing a GUI framework, MFC, .NET, wxWidgets, Qt, ….
The framework you choose will look after both the separation and the communication for you, as painlessly as possible.
Do not try to re-invent the wheel. The framework designers have put way more thought and testing into their implementations that you could ever afford to do.
Note that question #1 suggests that you are asking about separating the logic in a single application. However, later questions suggest you may be thinking of two separate applications, perhaps even running on separate machines.
I consider that having the GUI in a completely separate application will always result in something that will be slow and inflexible. However, if you do not care about speed and flexibility, and particularly if you already have the core application running with a simple console type interface, then this might be the best way to go.
3. Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
No.
If you are a single-person programming team, then you will be spreading yourself too thin trying to master two languages. If you are a multi-person team, why compound communication problems by setting up two different cultures?
4. Is it a good idea to have a browser-based GUI?
Not if you can avoid it. If you need a browser based GUI, then you will know it. If you do not need one then keep things simple and skip it.
5. Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
Same answer as #4
Some users already gave some good answers to your questions that's why I want to give you some tips how I handle my projects.
Q: On which OS should my application run?
Windows and Linux! -> I would use C++ or Java
Q: Is runtime speed important?
Yes! (calculations, graphing, access to system resources...)
-> In view of speed C++ is often faster (not always)
Q: Is a config file required?
A: Yes! I have to set some user and system specific values.
-> Could save config into registry but since we also want to use our application on linux let's use xml (rapidxml would be a good solution for C++)
Q: Is a database required?
A: Yes I have some information/calculations I need to save (local/global).
-> Local: I'd use sqlite
-> If you just have to save comparatively few information please consider a faster way for storing these information (xml?!)
Q: How should I structure my application?
A: ALWAYS keep apart your GUI from the "logic" part -> Makes it easier to change you code later and you'll be able to use your code for other projects as well. + the already mentioned reasons.
Q: How should I structure my GUI?
A: Think about what your application should be used for and what users should be able to do. Ah, and please don't create a too deep hierarchy which means that user shouldn't have to open 10 windows in order to open the window they want to have. Same goes for your code, it's not a wise decision to have too many objects which create a new object.
object->object->object->object->object->object->object->object
Q: Does my application has to communicate with a server application?
A: Yes? You'll have to use sockets! But keep in mind that communications via sockets aren't very fast and secure so don't use them if you don't have to.
Q: I'm not sure how to start (we are a group of developer)
A: When starting a new project I'm thinking about all these points (maybe some more) + In order to see which classes and methods I need, I start by creating a UML-Diagram which will help me to understand where I should start and the diagram will also help me to keep track of my classes and methods and how they are involved with each other. The UML-Diagram will also help your mates or clients to understand how your application will be structured.
For bigger projects I'd use C++ & wxWidgits or maybe Qt. (Just my point of view)
Rgds
Layne
If you want a good example of a cross-platform GUI solution that is free and well written, may I suggest you look at wxWidgets (1). I hope this helps
My answer is very generic as you didn't tell anything about your application.
Should the GUI be separated from the application's logic?
In the code, definitely. Running in a separate process, possibly on a separate machine, might also be a good idea, but this really depends on your requirements.
Reasons to fully separate it:
Running application as a daemon or system service (in the background) while the GUI is not running
Controlling the application remotely over a network
Possibility of multiple independent GUI implementations, using different programming languages (e.g. iPhone?)
Support for automated control (scripting) without GUI
Implementing the separation later, if not initially done, is almost impossible
Reasons why not to separate:
Serialization of all I/O is required, making the implementation harder
Slight performance degration if very large amounts of data are transferred (this really does not affect your typical GUI application in any way)
If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
HTTP is a popular choice and it avoids most problems with firewalls and such. In C/C++ you can use libcurl for http/https requests and Boost.CGI (not yet accepted to Boost) or one of the other CGI libraries for the server side.
Other options for IPC include shared memory (Boost.Interprocess), UNIX sockets and other network protocols. However, I would not recommend these unless very large amounts of data are transferred.
Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
I don't see much benefit from this. Still, separating the GUI allows writing it - possibly even multiple implementations of it - in different languages.
Is it a good idea to have a browser-based GUI?
Definitely. If what you need can be done with HTML5 and JavaScript, do not even consider a traditional GUI, just make it a webapp instead.
The benefits are:
Fully cross-platform
No installation of software on users' machines
All the clients always use the latest version of the GUI
Web GUI frameworks are actually nicer to work with than traditional GUI frameworks are
No need to separate the GUI into a separate process
Still possible to use from scripts (e.g. using the curl program from a shell script)
On the other side, you will get slight performance degradation, but once again it doesn't affect a typical GUI application enough to matter.
Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
The APIs of cross-platform GUI libraries are somewhat horrible. Qt does pretty good job at looking native nowadays and its API is rather good, even though it has a major impact on your application. Try to restrict any usage of Qt strictly to the GUI. The other option for true native cross-platform GUI is wxWidgets, which integrates better with other C++ code, but has a very nasty and error-prone API.
For web UI, you should definitely consider Wt, which is a high-level C++ AJAX framework, with an interface similar to Qt, but using modern C++ practices instead of taking over your application like Qt does.
http://www.wxwidgets.org/
http://www.webtoolkit.eu/wt
I agree with the commentators who said 'not enough information', but depending on your needs you should give a LOT of consideration to a web browser interface.
If real time streaming data and instant gratification interactivity are not important, the web interface can be fairly straightforward with no AJAX and just trivial form-based CGI and dynamically generated HTML. Keep in mind the part that exists as the browser is being updated for you with other people's money along with any change in Windows, Linux, Mac, or other systems.
Your users already find this familiar. You can find programmers to do the job.
Libraries exist already in almost every major language to embed a web server natively into an app, if needed. Or you can run a centralized server of some sort.
The browser already has a good means of separating content, input (forms), style, and enhancement where it will be easy to find people into the future who can develop or change out the relevant component.
Some people may say that's not good for standalone versions of the app, but I say that's fine for standalone as long as you add some security (run an embedded webserver where requests are only answered if they come from the local computer). The user's life can be made easier by starting the browser from the app or telling the user where to go in the startup message (the URL http://localhost:7654 or whatever, not their eternal destination :-)).
Should the GUI be separated from the application's logic?
Yes.
If it is separated, how should the logic and the GUI communicate? Are
TCP/IP sockets a good option? What are
other possibilities?
TCP/IP is going too far. Separate the application logic and GUI using OOP or any other structured programming approach.
Is it a good idea to have the GUI in a language different than a
C++? If yes - which language?
C++ is good enough as far as cross-platform apps are concerned. Other options are Java and .NET in which case, most of the cross-platform stuff is taken care of... though not with the degree of control that C++ provides.
Is it a good idea to have a browser-based GUI?
The best idea as long as your app does not need too fine a degree of control during user-interaction.
Even though the project's core logic is cross-platform, I can decide
that the GUI will be only
Windows-based (.NET?) and it will
communicate with the logic on the
relevant Win/Linux machine through
Socket or similar method. Is it a good
idea to do so?
IMHO the added complexity of using sockets is not worth it.
SciTE is a pretty good example a simple cross-platform application. The source code should be easy to follow for a Windows programmer. I suggest you download the source and have a look at how two platforms (Windows and GTK) have been handled the same code base.
You've god a lot of good answers, but still I'll write my own
Should the GUI be separated from the application's logic?
I think it's the best. So you can handle it easier when it come to modifications. Also, use a GUI framework that is multiplatform and has bindings for other languages, such as GTK+ or Qt.
If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
Sockets are a good choice or via threads if it's local communication.
Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
I think it's not the best option. Use the same language for everything if you can.
Is it a good idea to have a browser-based GUI?
As long as it's not too complex. I think the browser based GUIs are only for collaborative tools or absolute platform-independant (every OS has a browser) as far as you hold the main program in a server. As someone said avobe, if you consider doing a web GUI, consider first to do a webapp instead.
Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
Not in my opinion, it adds complexity, usually unnecessary, but if you really have to do that, yes, sockets are the best option.