In an application coded with C++ in Visual Studio 2015 and which aims to be cross-platform (currently supports Windows and Linux), is it possible to access NSEvent from Apple's Appkit?
Say, as an example, that one would want to retrieve which mouse button has been pressed by a iOS user: would it be possible for a C++ application coded in Visual Studio to retrieve the results of the function pressedMouseButtons(), that is part of the NSEvent object of thee Appkit?
If so, how should one should call such a function?
You can only call an API that exists on the target platform. So, unless someone has done a port of Appkit, no.
The usual strategy is to wrap platform specific sections with preproccessor conditionals (#ifdef). Your alternative would be to implement emulations of the Appkit functions and data structures you want to use. They don't have to be functional on the non-Apple platform, returning predefined test data should be enough.
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.
I'm writing a QT based native c++ app that uses QtSerialPort library under Win7. It communicates with it periodically(say every 5seconds).
Problem is: the device that my app connects to via serial port, has power loss issues(can't change this). When this happens my app becomes hung and immortal: can't be killed by windows task manager or by process hacker(a nice replacement for windows task manager)' termination facilities. Soft restart is the best solution at the hand.
Now how can my app cope with such device situation?
I would submit this question to Qt's interest mailing list (interest#qt-project.org). Since the QtSerialPort library is fairly new, bugs can appear when a wide user base starts using it. There is a good chance that the developers who wrote the library can give you a better solution or they find that this is a bug in their code and fix it.
I have a service application (no frontend) that was converted from C# to CPP native code not implementing .net framework. This was done to speed the processing and to reduce the footprint.
I am investigating the move to support this service to Window tablet devices. How would I go about this and what obstacles might I meet along the way?
TIA
You shouldn't expect troubles, even Windows Phone 8 will introduce full support for the C++, there is no relevant news that can make you worried about Windows 8 and C++, the only relevant thing is the addition of the WinRT to the usual set of C++ libraries for Windows but is more like an extensions rather than a set of libraries that will suppress something that is already existing in the Microsoft environment.
The only real changes are in the GUI subsystem, as you can expect just looking at the Windows 8 products and in this case under Windows 8, if you want a GUI, you probably do not have other options than switch to the new WinRT.
There is also this link that can be useful.
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
In your opinion, what is the best way to create gui in Windows ? with gtk or win32 api ?
Do you recommend GTK for windows ? Yes ? NO ? Why ?
If you are making the gui only for windows, I would strongly recommend WIN 32 Api. I have Made many applications in GTK+ , pyGtk , FLTK and have learned Qt, MFC and SmartWin++. Believe me , But I like Win32 Api the best. It may have a steep learning curve, but for creating native windows applications , it is the fastest and the BEST. And the more complex youre program gets, the easier Win32 Api is compared to other toolkits. And there are things you can do in Win32 Api, which you can not do in any other toolkit.
TESTED:
starting time (simple gui with menu and buttons):
GTK+ = 7 secs;
Qt = 4 secs;
WxWidgets = 3.32 seconds;
FLTK = 1 second;
Win32 Api = 0.34 seconds;
space taken:
Gtk+ = 132 kb;
Qt = 4.5 mb;
WxWidgets = 4.5 mb;
FLTK = 54 kb;
Win32 Api = 6.5 kb;
Let's see.
Win32 is very low-level, C based, and awkward to use.
MFC is considered obsolete.
C# (or C++) with .NET is probably your primary choice for Windows-specific development.
There are even semi-limited ways to port that code to other platforms (Mono).
Java is great for very platform-independent code that "just runs". Sorry, you said C++.
QT is relatively platform-independent.
GTK+, of course, although I personally don't have much experience with it.
Personally, if I do something Windows-specific, I use .NET - the tools in Visual Studio are very powerful, and it's a great all-encompassing suite.
For platform-independent stuff, I use Java, but that may not be your tool of choice. I've seen QT used a lot for that purpose.
You really have a lot of GUI toolkits/frameworks to choose from: Qt, wxWidgets, GTK+/gtkmm, WinAPI, MFC, .NET WinForms/WPF... and those are only the popular ones.
Since you limit yourself to C++, I'd strike out .NET because C++ on .NET is intended to serve as a connection between the unmanaged and managed world. That doesn't mean you can't use it for other types of development, but given the awkward syntax and countless pitfalls I'd not go with it. Moreover, the WinForms code generator of VS puts the forms' code into the header file.. brrrr
As others have stated, WinAPI is written in C, very fast and powerful, but very low level and not easy to program/learn. MFC would be an option since it's written in C++, easier to use than WinAPI and also very powerful. However, it's pretty much obsolete (due to the presence of .NET, mostly).
I wouldn't recommend GTK+/gtkmm (a C++ wrapper for GTK+) for Windows since you don't get the native windows look, it's rather annoying to set up on your developer machine and it also drags around tons of dependencies that you have to install on the user machine. That's actually a pity because especially gtkmm has a very beautiful class hierarchy and design. Probably one of the best designed GUI libraries :)
That said, what would I recommend? Either Qt or wxWidgets. Both are written in (fairly modern) C++, actively developed, have a good library design, run multi-platform and offer lots of functionality. In any case, play around with a few of the libraries listed in the answers here and see which one lets you do the things you want to do most easily :)
both are for c, but there is a good wrapper for gtk (gtkmm).
gtk has its own look, so theres no skinning of ui elements on the user side(with windows styles). but i like to programm with it more.
win32, mfc, .net are mostly limited to ms visual studio, while gtk is very hard to use with vs.
you should have a look on win32, .net, gtkmm and qt. just try to write and compile a simple hello world program with them
upsides of win32:
native windows code
fast
downsides:
no classes, only c with handles (very crappy)
in my opinion very bad documented
upsides of gtk(mm):
easy to learn/programm
good documented
downsides:
somehow difficult to install the development files
no native windows look
win32 api is too complicated, MFC is too annoying.
I have used MFC, win32api, and Qt in windows. In my opnion, Qt is the best one.
I havent tried GTK, so sorry knowing nothing about it.
Edit 2019: It looks all these options are outdated, how about the cross-platform solutions, react-native windows, electron
If Linux (or Mac) compatibility is your concern, then Qt. Else Win32.
I have used GTK+ in the past for a multi-platform application. I found it relatively simple to learn and use. To my mind the main advantage of GTK+ is that you will be able to port your application to other windowing systems. And the main disadvantage is that it will not look exactly like other windows applications. If you are doing cross platform work or are already very familiar with GTK+ (and don't have time to spend learning a new toolkit), I would recommend it.
Personally I prefer Qt, but it really depends on what kind of user interfaces you want to make.
Against Win32:
low-level, high complexity to accomplish trivial things. You have to do EVERYTHING
if you go this route I would recomment a book like the one from Petzold.
Pro Qt:
Good looking GUIs
Can change the look and feel very easily by creating stylesheets
Signal and slots mechanism notifies you of UI events such as "button clicked" etc.
Nice layout system
Integrated with Visual Studio IDE
Modern object oriented c++ code, easy to understand and use
Qt Assistant (Very good documentation)
Relatively liberal licensing (LGPL)
Qt Designer - WYSIWYG design tool you can use for form design
Comes with a wealth of other c++ functionality including XML, networking, eventloops,
threading, database access, etc
Against Qt:
Intermediary step of using MOC compiler
Pro WPF:
if you want the new WPF capabilities of the new Windows platforms, WPF is the way to go.
You may want to try Winforms or WPF. If you're limited to using C/C++, you can embed .NET code using the /clr option for the compiler to embed .NET code for Winforms or WPF.
Sources:
http://msdn.microsoft.com/en-us/library/k8d11d4s(VS.71).aspx
http://msdn.microsoft.com/en-us/library/ms754130.aspx
http://msdn.microsoft.com/en-us/library/system.windows.forms.form.aspx
Personal experience
For platform independent development, I would recommend Qt instead of the current GTK. GTK2 drawing was very slow compared to Qt as well as Win32. If you love native look feel, wxWidgets is made for you.