I am working on a simple socket application written in C, which allows two members to communicate over the internet using basic command line prompt.
I would like to add a proper GUI to it, just to use a decent UI and not basic standard input/output.
Right now I am developing with Cygwin to use POSIX threads and sockets. Is there anyway to hook it up to Qt?
As Shawn mentioned above, using Qt entails the use of an object-based language (probably C++ in your case). But there's another consideration -- Qt is a multi-platform framework; it can be thought of as a layer between your application and the OS it runs on. So, while the literal answer to your question is "yes," if you're going to use Qt for its UI abilities, you're better off (IMO) using its socket facility QAbstractSocket as well, rather than use the native (or Cygwin) socket API.
Related
I'm a little new to Qt. I have been programming in C++ for quite a while.
I want to create an application in Qt/C++ just because it's very easy to create the GUIs. I wanted to know that is it possible that I can write a C++ class in native C++ and use it in my Qt application.
I want to write the GUI in Qt and do all processing using my native C++ code rather than Qt/C++. Is it possible to compile a DLL in native C++ and then load and use it in QtC++ application?
I really want to write a GUI application using C++.
There is no such thing as "native C++" as opposed to "Qt/C++", so the question makes little sense. All of core Qt code is compiled native C++, just as any C++ application that uses Qt is.
As JBentley has duly noted:
[You may be] confused because of the code generating tools Qt uses, like moc [or uic]. Those don't mean that C++ compiles natively while Qt doesn't. All those tools do is provide a convenient way to produce a lot of boiler code that the framework relies on, so that the programmer can pretend they don't exist and use things like Qt's slots and signals. The final code which you compile and link is ordinary C++, with calls into the Qt library (also C++) which you've used.
If what you're asking is "am I forced to use Qt classes in all parts of my application", then no - nobody's forcing you to do that. If you already have parts of your application written using boost, or standard C++ library classes, it's fine.
You have to understand that Qt has modular design and provides a lot of non-GUI functionality. You can use the non-gui modules in the non-gui part of your code. It's a fairly clean and general purpose application development framework. It's perfectly fine to use it for various internet server applications, for example.
The following Qt modules are of note for non-gui development:
Core: Core non-graphical classes: containers, event loop, timers, threads, state machines, internationalization, XML, json, file I/O - all of it portable.
Network: Classes to make network programming easier and more portable. Includes secure sockets, HTTP requests, etc.
SQL: Classes for database integration using SQL.
You are able to use any C++ code you would like. I have have actually had questions with the same thought process in my day to day work. First you need to grok the idea that Qt uses normal C++ and special tools to create a robust set of libraries.
Later on come back and you will want to learn more about the items below:
Signals and Slots
This is how events are wired together.
One objects sends a signal and all connected slots get called with the given parameters.
Signals and slots are an example of the Observer Pattern.
Designer Forms
The form designer lets you lay out controls using simple drag and drop operations.
The .ui file gets transformed into C++ code as part of the build process.
Layouts
You can do a lot of things with just the horizontal, vertical and grid layouts
Spacers
You can push things up, down, left, or right using different types of spacers
They look like a spring on the form designer.
Resource Files
Lets you embed graphics and other content directly into the application.
Models, Views and Delegates
Hard to avoid if your have a non trivial UI
There are other things too, but knowledge in these areas will let you make some decent desktop applications. My favorite reference is older, but still a goodie: "C++ GUI Programming with Qt4" http://www.amazon.com/Programming-Edition-Prentice-Software-Development/dp/0132354160
Yes QT4 is "old" and QT5 has been out for some time... but the book provides a solid foundation that you will be able to add information to.
I've been away from GUI programming for quite some time so please pardon my ignorance.
I would like to attempt the following:
Write a Mac OSX app but still be able to port to Win/Linux (i.e. C++ core with Obj-C GUI)
Avoid Qt/other toolkits on OSX (i.e. talk to Cocoa directly - I feel that many Qt apps I use stick out like sore thumbs compared to the rest of my system)
Not as important, but it would be nice to avoid Visual Studio if it means I can have the freedom to use newer C++ features even on Windows if they help create better code.
I believe this configuration might get me what I'm looking for:
Core C++ Static Library
OSX GUI (Cocoa)
Windows GUI (Qt+MinGW?) OR (no new C++ features, Visual Studio + ManagedC++/C#/????)
Linux GUI (Qt)
Once again, sorry for my ignorance but is this possible? Is this sane? Are there any real-world open source examples accomplish something like this?
There is quite a few OS X applications that have completely custom-designed looks that don't use very many stock controls. iStat Menus comes to mind, but there are many other examples. They still look good, but it's done by manually designing them to look good and to "mesh" with the overall look of OS X applications. Even their preferences pane doesn't use stock buttons.
Thus, you can go quite far using Qt, you just have to pay close attention to what you're doing - similarly to the way other developers are paying close attention even when using Cocoa. You'll find that Qt's controls offer functionality often above and beyond what's offered in Cocoa.
That said, on OS X sometimes you may need to run some native code that expects a CFRunLoop to be present. It's good to know that Qt's event loop already spins a runloop for you, so as long as you have an event loop spinning in a given thread, you can use runloop-based code - the default runloop is provided by Qt's implementation of QEventDispatcher (somewhere in its guts). For non-gui threads, the unmodified QThread does it for you. This is useful for using asynchronous IOKit functionality, for example. Another answer of mine presents some Cocoa mouse event grabbing code. A previous version that used Carbon can be found in the edit history of that answer.
Same goes for Windows: Qt runs a message sink for all top-level windows it owns, and you can integrate native controls/windows using qtwinmigrate. You can also integrate ActiveX controls using the Active Qt framework.
Well I think you should try Qt even on OSX. Qt allows native/custom look of applications (those cases you mentioned are probably bad examples - you probably haven't noticed that lots of other applications also use Qt).
Tools I usually use for multi-platform development:
C++ (now C++11 since all major compilers more or less support it)
Boost
Qt
CMake as build system generator
If you use this tool-set you can choose whichever platform you like for development and still be multi-platform without extensive work on the other platforms.
From the answers recieved for the question here: Graphics using Standard C++ only?
Seems to be that C++ itself does not have GUI functionality. So how do other Frameworks like Qt which support GUI in C++ do that? Do they use some other language internally or is there some other standard lobrary/protocol for GUI?
And I am concerned about the C++ language frameworks only.
Thank You.
They call operating system APIs, or APIs in other frameworks, in order to create GUI components.
Eg. on Windows they call the Windows CreateWindow API to create a window.
Where a framework works on multiple platforms, it contains different GUI code for each of those platforms, calling CreateWindow on Windows or whatever the Mac equivalent is on a Mac, for example.
I'm implementing a GUI program (a cards game) in gtkmm (at the moment). I want that my program runs well at least under Windows and Linux (GTK). Mac OS X would be a plus, although not required. Although I'm using gtkmm, I have some concerns with it.
More concretely:
Lack of support for connecting signals at runtime.
The API for treeview is horrible in the sense that you need to make your own classes
in c++ code every tie you have a new Treemodel.
These two things get a lot in my way when implementing GUI code. My questions are, if I switch to wxwidgets:
1.- Is it possible to connect signals at runtime?
2.- Is the ListCtrl API from Wxwidgets comfortable to use in your opinion?
3.- Is there a decent gui builder (preferably free, but not required) in which I don't have to connect signals by hand in c++ code? This is quite important to keep controller and view code separated.
4.- Is there an alternative to wxwidgets which is better and looks good under gtkmm, besides working on Windows. I'd rather not use qt with its preprocessing step
Thanks in advance.
It is possible.
ListCtrl if just fine to use, and you will maybe find some nicer alternative (UltimateListCtrl, wxGrid...).
wxFormBuilder.
Not that I know of.
I have a old school c program that now and then
need to tell a C++ Qt based application about some "events" that has occurred on my system.
But when I started to work with this problem I noticed that some ipc techniques is quite easy to use in the c program.
And then we have some Qt specific styles that works quite well in the "Qt world",
but they will not work well in the ansi c program.
Do you have any advice on ipc techniques that works well and are easy to use in both a Qt C++ and a c program?
Thanks
Johan
If you are familiar with network programming, Unix domain sockets should be easy also. They work kind of like bidirectional named pipes and the network API in Qt should make it easy to receive "events" delivered as network messages.
What about named pipes? You can operate on them just like on regular files (creation is a bit different of course), and I bet both old ANSI C programs and new Qt C++ programs can operate on files.
If the event notifications are very simple then you could use signals.
If the notification is useful from/to outside sources then D-Bus is an option.