Imagine you are on Windows 7 and you have to write a GUI for a GRAPHIC application, (like a terrain editor, mesh viewer ..) which involves a great use of DirectX and OpenGL (so written in native C++).
If your goal is a multi-platform software then you should go for wxWidgets, but imagine you're doing a Windows' only app...what would your choice be? and why?
I'm supposing that the application would work on both XP and Vista/7 and obviously in the WPF case the UI will be managed, but it will call native functions by a C++/CLI proxy-like class
( will "bouncing" from managed-native and native-managed cause performance issues? ).
RAD Studio can also make the job
Enhanced in 2010! VCL (Visual
Component Library) for rapidly
building Microsoft Windows
applications now includes seamless
Windows 7 support, and graceful
fallback compatibility with Windows
Vista, XP, and 2000
Enhanced in 2010! Windows Vista and
Windows 7 API headers to fully
exploit the latest Windows
capabilities
New in 2010! Support for Windows 7
Direct2D API
you can also make WPF with Delphi Prism and wxWidgets with twinforms
If you are comfortable with your C++ skills, I recommend WTL. It is very lightweight and results in lean machine code. The Windows version of Google Chrome was written with WTL.
To minimize development time and maximize performance I would definite go with Delphi 2010 (Rad Studio 2010). You get native execution, direct interfaces with Windows 7 Direct2D API, and arguably one of the best IDE/Development environments available on Windows 7. What else do you want?
Larry Drews
TheSoftwareRonin
You might consider using Qt, even for a Windows-only app, simply because the Qt C++ API is so nicely done. Qt supports OpenGL and can be used in conjunction with DirectX.
In WPF, you can actually use DirectX Shaders to apply effects on interface objects, (here's a CodeProject article detailing development aspects) and it is expected that the support for this will continue to grow, so I would choose WPF as a development platform. Furthermore, it focuses on creating attractive user interfaces with a reasonable amout of effort, and I think this is quite important in building a Graphics oriented aplication.
will "bouncing" from managed-native and native-managed cause performance issues?
definitely, but since you write just editor (not a game, in general) it's not a thing you should worry about
WPF applications rendered by DirectX subsystem as i know. so if you using only DirectX it will be a good choice.
I would personally use http://sourceforge.net/projects/win32-framework/ to create any Windows based applications in C++. Otherwise I would just use VB.Net or C# because you can easily port code between both and the form designer is very useful.
MFC :: Just say NO for any kind of project.
Win32 :: Well, I can not really recommend using it.
wxWidgets :: I have used it and seen no problem, good choice.
WPF :: I have not and never will use it as it is .Net bound.
FLTK :: Also look at http://fltk.org/, probably has better OpenGL support.
Be sure to check out WDL ("whittle") by the Cockos team (headed by Justin Frankel of Nullsoft/Winamp fame).
It's an extremely lightweight C++ library that includes "WDL Virtual Window system."
I personally haven't used it, but I can vouch for some great software that's been made with it. Extremely efficient and lightweight apps.
Link: WDL
I can't really comment on wxWidgets, but WPF is vastly superior to MFC and good old Win32 API. WPF uses DirectX for rendering and there are some 3D support in WPF. Unfortunately this support is still somewhat rudimentary and not the most performant. You can actually get better 3D performance if you host a Windows Forms control that renders OpenGL (at least we had to do that in a recent project I worked on). If you want to do 3D rendering in a WPF application you could have a look at the XNA Framework. The next version of the .NET framework will also include improvements to WPF and I'm sure there will be better support for 3D.
Related
I need to write an application that will be visually indistinguishable from something written natively for Windows XP/Vista/7 using whatever comes by default with the most modern Visual Studio. But I'm developing using MinGW and Vim (in C++).
In particular, I want the following controls to be native on the above three versions of Windows: form chrome, buttons, check boxes, menus, combo boxes, progress bars, scrollbars, rich text boxes. This will be enough for me.
I know that if you load GdiPlus and other things like riched32.dll as needed, and use Windows API to instantiate controls, then the OS will substitute its version of GdiPlus or other library, so it will look like XP style controls on XP, Vista on Vista, etc.
But I don't want to use plain Windows API, because even retrieving the default font takes half a page of code, and similar stories whatever I want to do. So I'd like to use a toolkit.
wxWidgets, Qt, GTK+, FLTK seem like the most widely used. But they are all cross-platform. I've used cross-platform applications, and many of them have foreign GUI controls (I call them widgets). So my question is: which of these toolkits can be made to produce true native-looking UI controls listed above, appearing correctly on the three versions of MSWin listed above?
I've typed each of them +" windows" into Google Images, but it's hard to tell, except that FLTK probably can't do it. Many of you must know the answer off the top of your head...
I won't talk about FLTK as I don't know it.
wxWidgets uses the native toolkit of the platform, (GTK on Linux, Win32 GUI API
on Windows, Cocoa on MacOS X).
GTK uses a theming API to fake the look and feel of the platform (custom theming engine on GTK2, CSS-based engine on GTK3).
Qt uses styles to fake the look and feel of the platform.
wxWidgets API is quite ugly from my own experience, because it had too many method just available on one or the other platform making stuff non-portable unless you'd workaround it. Unlike GTK+ and Qt, it also adds its own layer of bugs above the toolkit it uses as a backend. However, it tries hard to have the platform's native look as it uses the native toolkit.
GTK+ 3 still has some rough edges on Windows, which it officially supports since GTK+ 3.6. The GTK+ project delegates to the MSYS2 project the distribution of Windows binaries. As you're already using MinGW, that's pretty much the same kind of environment. They have good C++ bindings with GTKmm. However, you may have some work to get the theming right for your version of Windows.
Qt is a good choice for cross-platform C++ development with the main target being Windows, tries to mimic the native look and feel of the platform but has its own theming limitations too.
To sum up, there are only 2 approches:
toolkits that provide their own widgets and try to look like the native platform by providing theming (GTK+ and Qt)
toolkits that use the native widgets but hide their API behind a layer of abstraction (wxWidgets)
Both have their pros and cons.
Implementation details aside, wxWidgets philosophy is, and has always been, to look as natively as possible. We, wxWidgets developers, don't always achieve the goal of looking indistinguishably from the native applications but we always strive to do it and. AFAIK this is not such an important goal for Qt and definitely not for GTK+, so in my (obviously biased) opinion, wxWidgets is your best choice if you are serious about providing the best experience for your users, especially under OS X.
To answer your question more precisely, everything you list above is implemented using native controls in wxWidgets for Windows (rich text control is not available natively under the other platforms though).
IUP - Portable User Interface library uses native widgets, C API and Lua bindings.
i used java for native cross-platform without changing the code, used c/c++ wxwidgets for exclusively cross-platform if you want go to little up performance and standalone executable, used c/c++ winapi for windows and x11 for gnu linux native platform and terminal console, used python for scripting console and platform if you want your software up to date fast, and used assembly for a little simple purely console. And sometimes i combined them all with shared library .dll on windows and .so on gnu linux. And i liked doing for do comparative performance on programming studies with small hardware requirements.
I want to create a C++ UI framework (something like QT or like ubuntu unity Desktop)
How is programmed , is it using OpenGL or lets take plasma ui of QT (how is this programmed )?
Direct answers , reference links anything will be helpful.
Some interesting opengl based UI I founf on the web
LiquidEngine
http://www.youtube.com/watch?v=k0saaAIjIEY
Libnui
en.wikipedia.org/wiki/Libnui
Some UI frameworks render everything themselves, and work based on some kind of clipping-window-within-the-host-systems-screen. Non-display aspects (such as input event handling) have to be translated to/from the host systems underlying APIs.
Some UI frameworks translate as much as possible to some underlying framework.
wxWidgets can do both. You can choose a native version (e.g. wxMSW if you're on Windows) and most wxWidgets controls will be implemented using native Windows controls. Equally, you can choose the wxUniversal version, where all controls are implemented by the wxWidgets library itself.
The trouble is that typical GUI frameworks are huge. If you want a more manageable example to imitate, you might look at FLTK. I haven't got around to studying it myself, but it has a reputation for being consise.
There are also some GUI toolkits that are specifically aimed at games programming, such as Crazy Eddies GUI. My guess - these are probably as idependent of the underlying API as possible, so that particular applications can implement the mapping to whichever underlying API they happen to target (OpenGL, DirectX, SDL, whatever) and can be the boss of the GUI rather than visa versa.
http://www.wxwidgets.org/
http://www.fltk.org/
http://www.cegui.org.uk/wiki/index.php/Main_Page
"no really, don't write your own wm or toolkit"
The #Xorg-devel guys on irc.freenode.org
doing one anyway means that you have to test against a wide range of more or less buggy WMs and X implementations, and that you have to frequently update to be compatible with the latest Xorg server and X protocol features (like Xinput 2.1)
understandably, the Xorg people are tired to support old, unmaintained toolkits and applications. They already have enough bugs.
The GUI frameworks are very dependant on a windows system, which dictates what is allowed and how windows are created and rendered. For example, pass a specific option to create a borderless or full-screen window.
Since you mentioned opengl and ubuntu, I guess you want to start on a linux platform. You should study xlib, for which you can find reference here.
Since the qt library is open source, you can download it and peek into it's sources.
A UI library isn't developed from scratch. It relies on the OS' windowing system, which relies on the driver from your graphics adapter, which relies on the OS kernel, which relies on... and so on.
To develop any software "from scratch", you can start by writing your own BIOS. Once you're done with that, move on to writing an OS, and then you should be just about ready to write the software you wanted. Good luck.
And this is assuming you're willing to cheat, of course, and use a compiler you didn't write from scratch.
Before you do that, it's worth that you spend one week on thinking:
1, Do you really know how to do it? I doubt that.
2, Do you really need to do it? I doubt that too.
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.
I want to develop native c++ windows application using windows API.
but i find it being difficult because i am unable to render the window and drag and drop components, change the location etc..
How can i view, drag and drop components like i can do in C# ?
May be there is no way to do. if so, what is the fastest procedure to design the application ?
If you like so much the drag and drop of components (and of course for good reason) why would you need to develop it using C++? You can use PInvoke if you need to call some C++ functions from C# code that are not in the .net framework.
But if you really insist, maybe you could try QT.
Using a library framework such as Qt is really the way you want to go. It makes things very simple and still allows you to write code in std c++ to keep most things very fast.
If you EVER have intentions of porting the code to a different platform than windows (whether it be Mac, Linux or even Android ... yes its possible), qt is definately the way you're going to want to go.
I can get an app up and running... smoothly in a few minutes using Qt but much longer and with more confusion using MFC.
Dragging and dropping 'widgets' to form a gui is very easy and possible with Qt's built-in QtDesigner!!! Check it out!!!
http://qt.nokia.com/downloads
Assuming you are using Visual Studio, if your app can be implemented as a dialog box, then you can use the dialog editor to lay things out. Otherwise, you just have to write code to create the windows and place controls. Look at the MFC examples included with Visual Studio.
Jeff Prosise's PROGRAMMING WINDOWS WITH MFC was one of the better books for learning how to do this, but I think it is out of print, and so could be hard to find.
Charles Petzold's PROGRAMMING WINDOWS is the bible for the Win32 API. Again, may be hard to find these days.
If MFC isn't your cup of tea, you could also look at QT, GTK+, or wxWidgets. There are GUI builders for each of those, but they are all pretty primitive compared to what you can do with C#.
As far as I know there is no ide out there that will let you "drag and drop create" standard win api windows like you would with C#.
Personally for that kind of application I always recommend Borland C++ Builder (Which is now Codegear Rad studio)
Although it is not standard API, it allows you to drag an drop and static linking is very easy, so you dont have to worry about redistributables
I just wondering about this.It is said that .NET is better than MFC in a lot of aspects.But when I use my PEID to recursive scan my 'program files' directory,it turns out there are still a lot of programs written with 'Visual C++ 6'(esp. for security software),whose GUI should be written with MFC.
So my questions are:
Is MFC still the dominating framework
for windows desktop aplication?
What frameworks do IE,firefox,Microsoft office(or other famouse desktop applications,if you'd like to list some) use?
What frameworks do the desktop applications(e.g. explorer,card games) of Windows itself use?
thanks.
I say windows forms and WCF are pretty widespread. C#/VB.NET are well-entrenched in corporate america.
IE is COM-based.
Office is MFC/COM.
Windows Apps are usually native code to demo the platform.
For new projects I don't think MFC is the dominant platform, but mostly because newer platforms shield developers from the idiosyncrasies of Win32 and MFC itself and allow for faster development. MFC applications take longer to develop but are, imo, unmatched in responsiveness.
I will not deny that some parts of the platform are irrelevant in 2010 (for example CArchive and most of the Doc/View foundation); on top of that, the dwindling availability of 3rd party components (mostly GUI) is a bit worrisome. FP1/MFCNext was a step in the right direction, I'm anxious to learn about the new MFC functionality in VS 2010.
For optimal integration with the OS, imo C++/MFC is still the best choice because of the nature of C++ as low-level and the fact that Win32 is still the foundation of Windows and that it can most easily be accessed in C or C++.
By the way, I had to write code to change screen resolution and found that C# could only handle detecting screen resolution but not changing it.
To change resolution you had to do a lot of Interop gobbldygook which I tried but was too complex because the Win32 APIs to do that had too many old style arguments.
So, instead I wrote a quick MFC DLL that accessed Win32 API directly and wrapped all the calls to Win32 in a simple API. Then I did an interop call to my simple API in an MFC User dll.
Everything worked fine.
So, there's still no substitute for Win32 API. That has the ultimate power, and you have full access to it via MFC. So, yes MFC is still relevant and so is ATL and so is direct Win32 all of which I'm forced to use from time to time.
So, you may get 90 percent of your work done with .NET, but you have to go under the covers for a few things. Also, I've done a lot of Qt, and would never use it for quick jobs that are windows only. Qt also has become prohibitively expensive if you're doing anything commercial and also it is very very bloated. It's libraries take up gigabytes.