Let's suppose you're an IT student with a basic knowledge of C++ and C#. Let's suppose that you want to design apps that:
need to deliver some performance like archivers, cryptographic algorithms, codecs
make use of some system calls
have a gui
and you want to learn an Api that will enable you to write apps like those described earlier and:
is mainstream
is future proof
entitles you to find a decent job
is easy enough - I mean easy like VCL, not easy like winapi
So, making these assumptions, what Api will you choose? MFC, WPF, other? I really like VCL and QT, but they're not mainstream and I think few employers will want you to write apps in QT or Visual C++ Builder...
Thanks for answers.
Note: The following answer was written several years ago with Desktop application development in mind. Today (in 2018), you'd probably just build a web application to end up with something reasonably cross-platform and device-independent. (For example, using ASP.NET Core on the server side, coupled with a UI framework/library such as React, Vue.js, or Angular on the client side).
Win32 API -- I'd forget about it, if I were you. Programming a Windows application directly via the Win32 API only makes sense if you're programming in pure C, or if you really need to do a lot of system calls, or if you're concerned about the additional overhead introduced by more "comfortable" platforms or frameworks (such as the ones named below). Programming UIs directly through the Win32 API is tiresome, messy, and you need to deal with lots of details. It's also not platform-independent at all, but you may or may not be concerned about that.
MFC -- Perhaps an option if you're programming in C++ and fixed on the Windows platform. I never understood what's so great about it, other than it makes the Win32 API much more comfortable (AFAIK it's basically a collection of object-oriented wrappers around the Win32 API that take away some of it's complexity / messyness). Also, it's also not very platform-independent.
Qt, wxWidgets -- Fairly widespread UI frameworks. Might be good options where platform independence plays a role. AFAIK both frameworks are targeted at the C++ language.
WinForms (.NET) -- Similar to MFC, this is also based on the Win32 API (USER32 and GDI+). AFAIK the WinForms framework is now being ported to Mono, and therefore somewhat cross-platform. However, it's not exactly the most up-to-date technology. For complex UIs it can also be somewhat sluggish sometimes. If I had to decide today which framework to use, I'd rather choose...:
WPF (.NET) -- More modern than WinForms, with more graphical capabilities and, apparently, faster rendering, as it is no longer based on the Win32 API (GDI). (And it runs on .NET, which I find a great platform to develop for. Programming in C# is so much easier than programming in C++ IMHO, which is also an argument against Win32 API, MFC, Qt, and wxWidgets.) Note that WPF is not cross-platform, it exists only on the Windows platform so far.
Then of course there's Java, including the UI frameworks that come with it. I can't say much about that since I'm not a Java person, but I could imagine that Java would be the best choice for platform independence; and it's the dominant platform (over .NET) in certain industries (e.g. mobile phones, banking, due to the very solid JVM and security considerations).
So my recommendation would be the .NET framework, and WPF for the UI, if you're planning to stay mostly in the Microsoft world. Remember that you can still use the Win32 API (you won't come closer to "system calls" than that) via P/Invoke.
If you enjoy coding in C# and working with the .Net framework I'd recommend that you have a look at WPF. WPF is a great GUI framework where you can do just about anything - and also make it shine! WinForms might be easier to get a grasp on, but I'd say WPF is more "future proof". Another positive thing is that WPF is really similar to Silverlight, so if you handle WPF well you should be able to write Silverlight applications too - if that's of interest. Please don't bother to learn MFC.. I can't believe there are many that is using MFC today for other reasons than that they were using it before, and didn't get an opportunity to change..
There are a lot of good jobs out there for .Net programmers, so being able to handle some GUI framework in addition to C# and general knowledge about the .Net framework will be worthwhile.
When it comes to your points about being able to "deliver some performance like archivers, cryptographic algorithms, codecs" this really shouldn't depend on your choice of GUI framework. This kind of code will be writen in layers outside of the GUI layer, and will typically be bound to the GUI. With WPF you'd write your e.g. cryptographic algorithms in C# in some class independent of the GUI layer, and then the View written in WPF would bind to C# code and get its answer from here. However, if you used WinForms you'd still do the same thing, and the performance relies on the algorithms - not the GUI.
When it comes to getting started with WPF there are a lot of questions on SO helping with this. So you should find good help with a quick search.
Good luck!
Related
I have been working for some time on a library which performs numeric calculations. It is written in pure native C++, and until now I have been using simple console applications to test its functionality.
The time has come to build a GUI on top of the library - to better display tables of results and also to render them in graphical form.
I was always planning to use WPF to implement the UI and have spent some time researching it, but I am now having second thoughts. My worries about WPF are:
Is it worth coupling my program to the .NET framework just for the sake of the user interface? .NET and WPF seem to add overhead in many forms, including:
Program complexity
Using .NET implies using a second language - and thus writing lots of messy interop code.
Runtime performance
In particular, WPF applications seem very slow to start up.
Deployment
Is .NET framework installation quick and easy? Does it require rebooting the machine?
Rendering quality
This has improved in WPF 4, but display of standard elements still seems poor in some areas.
Concern over whether performance and quality will improve in the future
Is it true that WPF is being de-emphasized within Microsoft (in favour of Silverlight)?
My worries are compounded by news of people moving away from WPF having faced similar issues - the most recent and highest-profile being Evernote.
Would you recommend I stick with my original plan and use WPF?
If so, what do you think about the above issues?
If not, what alternative libraries could I use to create a high-quality Windows GUI?
Edit:
Thanks to Reed Copsey for addressing my individual points. The reply suggests that most of the issues I have with WPF can be worked around.
It seems that using WPF will involve more work than would be ideal - including writing interop code and making tweaks to ensure good performance and high quality. Do people generally agree with the statement that, in spite of this, the best way to produce a top-quality UI is with WPF - rather than with any other framework?
I'll try to address these in order. Spoiler: In my opinion, for the most part, the answer is yes.
Is it worth coupling my program to the .NET framework just for the sake of the user interface?
This depends on the interface requirements. Do you users need a good, solid, modern UI? If so, you'll want to use the right tool to deliver that requirement.
.NET and WPF seem to add overhead in many forms, including:
Program complexity
Using .NET implies using a second language - and thus writing lots of messy interop code.
You can use GDI+ via C++/CLI, and handle everything in one language. That being said, part of the reason people use other languages for this is productivity - it's actually very, very fast compared to making a GUI in C++. The interop code via C++/CLI is not very messy at all, at least not if your routines are class-based.
Runtime performance
- In particular, WPF applications seem very slow to start up.
This can be an issue, to some extent. You can do a lot to mitigate it, however - but this will probably always be a bit slower to start than a lean, native codebase since it has to spin up the CLR + libraries.
Deployment
- Is .NET framework installation quick and easy? Does it require rebooting the machine?
Yes on both counts, typically. That being said, most people already have the framework installed (esp. if you target .NET 3.5, but 4.0 is coming along nicely), so it's a non-issue. I always see this as a one-time thing, though - I'd much rather trade a nice user experience for a bit of deployment time, especially when it's a relatively pain-free deployment (.NET's very easy to install, just large and a bit time consuming).
Rendering quality
- This has improved in WPF 4, but display of standard elements still seems poor in some areas.
I'd strongly disagree here. WPF is (esp. in v4), the premier platform for quality user interfaces. It's tough to beat the rendering quality options in WPF -
Concern over whether performance and quality will improve in the future
- Is it true that WPF is being de-emphasized within Microsoft (in favour of Silverlight)?
No. There was even a good talk at the PDC of the future of WPF. Silverlight gets a lot more press, but that's mainly because it's not nearly as mature of technology, so it's changing more quickly. WPF is still their top of the line UI experience, and still getting new features added. It's also the suggested platform for interop with native code - while it's possible in SL using COM, it's not pleasant like in WPF.
Performance, threading issues, and airspace issues seem to be the future improvements in mind, according to the PDC talk. For details, watch "The Future of WPF."
I want to write a standalone GUI based app for administering one of the most popular enterprise middleware products from a very big company. But that big company already has a admin tool and its free.
But guess what , its very very slow , since its written on the java/Eclipse platform.
I want to write a very fast responsive GUI tool natively for windows.
I do not have much experience programming for windows , So what library(open source preferably) i can use on windows to get the job done.
Note: I need to write it in C, Not C++ , But if i dont have any choice I guess i can do with C++.
So I basically need to write a GUI app in C with some good GUI library.
Please help me out.
Thanks.
Edit : I do not know OOP and don't prefer using it.
Edit : So my choice is down to Win32API and Qt.
my requirement is that of a simple GUI , nothing fancy. I will be using simple windows ,buttons and menus. But I may need to do some processing , which means GUI should not take up much resources.
Based on this I m thinking of using Win32 API , even if I have to take the pain to hopefully satisfy the users.
its very very slow , since its written
on the java/Eclipse platform.
Are you sure that this is the reason for the application's slowness? I am no
fan of Java, but before you reach any conclusion, have you made sure that
writing the software in c makes it noticably faster? It could be that the
application is slow for reasons that are not under the control of the GUI programmer,
such as a slow database or bad network latencies.
Also, I don't mean to be rude here, but do
I want to write a very fast responsive
GUI tool natively for windows.
and
I do not have much experience
programming for windows
not contradict each other?
If you want to write a C GUI app, stick to Win32 or GTK+.
Win32 is blazingly fast, and will let you access everything available to Windows. Take a look at this tutorial.
GTK+ is extremely easy to use, cross platform, and provides tons of extra functionality. Start by downloading the all-in-one bundle, and move onto a tutorial and the documentation.
Personally I'd recommend going straight to Python if you need quick, responsive GUIs, and just need to wrap some lower level stuff.
Why are you limiting yourself to C? Windows Forms and WPF and SIlverLight are all viable UI frameworks that are responsive and have tons of books. There's a reason you can't find much info about writing GUI apps in C - people don't do it.
For plain C, cross platform, native look, simple, scriptable UI, I suggest to have a look at IUP: http://www.tecgraf.puc-rio.br/iup/
If you really have to use C then you can use GTK+. Otherwise, I'd suggest a C++ library like QT or wxWidgets. However, that being said I still think it would be preferable to build a .NET (Windows Forms or WPF) solution. They should provide a better UI experience than Java/Swing.
If you really want to do it in C, you could use the Win32 API. But it's hell working with it. The Object Oriented variant isn't much better either, but it takes away a bit of the pain (MFC).
I strongly recommend you to use C++ with the Qt library, which is both cross-platform and open-source (LGPL). C++ Qt GUI applications are as fast as native Win32 applications, although they take more memory. And you can't even start comparing the productivity gains - Qt is a great library, terrifically designed for GUI programming with tons of other useful tools.
Most GUI toolkits are written in C++, so restricting yourself to C will limit your options somewhat. One option that is cross platform and written in C is GTK; it's originally for X, but runs on Windows as well.
edit: Of course, you could always just program directly against the Windows API (formerly know as Win32) itself. For simple GUIs, it's not too bad.
GUI components map very well into Object oriented paradigm. Using C for GUI applications is a bad idea, I've been there and it's much more confortable to do it in an propper OO fashion with C++. Of course you can sort of do OO with C but it's ugly to say the least.
In my opinion, more than the GUI frameworks you need to really work on the design of the application you building.
For a normal GUI in C/C++ Win32 provides enough of controls for a decent looking application with good response time.
What you should really focus on is how to make it multi-thread based upon the time your modules take for execution.
Consider this small example: You have a DataBase connection monitoring in your GUI which is probed every second. Another module may be sending some big files to other applications. Now if an application is single threaded, your GUI is bound to have response problem. If you database connection is very slow due to some network/db issue your app will hang irrespective of the GUI frameworks or hardware chosen, if it was a single threaded app.
But if you write a good design and dedicate a separate thread for GUI handling and other threads for handing background tasks, you will have a really good GUI response. That way you can perform other tasks in background and GUI gets updated when notification is obtained. Remember, it wont happen magically and you need to sync you threads and update GUI.
Also, avoid creating threads for each and every task. You need to check things which can take more time like sending big files or faster tasks like checking/reading if config file exists or not.
By using third party GUI frameworks you are increasing your dependencies in your application and you would require to ship additional dlls etc with you main application. With win32 things are pretty neat.
I'm looking for some arguments to pitch to my boss and fellow developers.
We're currently finishing up the preliminary UI mockups and getting ready to move on to the next phases of development. In the meantime, I've been digging through the depths of the Carbon, Win32, and wxWidgets APIs attempting to make some of the controls have a more native look and feel on the Mac and Windows platforms.
The more I dig into the Win32 and Carbon APIs to implement the things we want in our project's UI, the more antiquated they feel, and the more I'm beginning to think that we should be implementing the project as described in the last paragraph here.
We're using wxWidgets for our current projects. wxWidgets is coming along on the wxCocoa port, but it doesn't look like it's going to be ready for prime-time before we start major development efforts on our new application. On the Windows side of things, it wraps the Win32 API rather than WinForms or WPF (likely due to native vs. managed code).
We're already designing the system with the MVC pattern in mind, thus aside from having to write two native UIs, it should be very doable, and, IMHO, easier to get the desired UI effects using modern APIs such as Cocoa and WPF.
I've been trying to push these points subtly, but the start of major development is coming soon. Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?
Thanks in advance.
Create your core code in Standard C++ and use Objective-C++ with Cocoa to create your user experience on the Mac and C++/CLI plus C# with WPF to create your user experience on Windows. Follow the platform guidelines for the Mac in your Mac version, for Windows in your Windows version, and don't even bother thinking about trying to share user interface code.
One good way to manage this is, instead of just Model-View-Controller, following a Model-Model Controller-View Controller-View architecture. Your Model Controllers are platform-independent and manage the higher-level functionality of your application. (For example, its entire concept of documents, file format, job queues, and so on.) Your View Controllers are platform-dependent and mediate between your Model Controllers and your user experience.
Of course you'll probably also want some platform-dependent code at the model level too; for example to use NSOperation on the Mac and thread pools on Windows to implement job queues. Just create your own lightweight abstractions for that sort of thing.
Actually I think using Qt has become very interesting since it's now LGPL
Every time you add a layer of abstraction, you trade control over the details for more rapid development. You'll be able to get a lot done up-front using some cross-platform framework. On the flip side, when you want to do something that the framework doesn't support—and lets face it: it isn't going to implement all possible things those native APIs can do—you either have to implement it (for all platforms) using the native API, or do some other wierd hackery to get a "good enough" solution. And of course, when things go terribly wrong, having that extra layer of code you don't own makes it harder to debug. There really is something to be said for owning your entire stack as much as possible.
Writing two font ends is a lot of work, maintaining two front ends is a huge amount of work, if you need your program to run on multiple platforms go with a multi-platform toolkit.
If you write platform specific front-ends, each using the state of the art tools for that particular platform, you will get a much better user experience - but the cost of developing and maintaining those will be on the same order of magnitude as developing the entire application from scratch for each platform (yes, even with MVC).
Personally, I'd rather stick multiplatform and don't give a damn for that eyecandy, but if I wanted to pitch the use of those native APIs, I'd work out the (end-user-visible) differences between how things are done in different GUIs. If you can convince them that, in order to feel native, the program's user interface has to look and feel very differently on Windows and OSX (because of different design guides/philosophies/whatever), they should understand that, even with wx, you would still have to implement it twice, to accommodate those different requirements, so you might just as well use the real thing, i.e. the native API.
Also see this thread on the Google Chrome mailing list discussing the same choice of UI for Chrome on different platforms.
Win32 is definitely waay to old, but you might want to look into something like Microsoft Foundation Classes which is designed to do native development with C++. I assume that a similar thing exist for MAC.
Personally if I was in your situation I would properly also go for QT or WX.
Does anyone have any suggestions on how to pitch using native UI toolkits in our next application vs sticking with wxWidgets?
No one likes a corridor-wiseass.
I think action speak louder than words...make a small prototype of how you think it could be done, and show it. Maybe you have to do this in your spare time.
Cocoa is really great so I think that with little code you can show an idea...well, this require that you know Cocoa enough.
I am in the beginning stages of creating software for a mISV-to-be. The program is a desktop application and in the long run I want to have a native version for both Windows and OS X (I have a looked at various cross-platform APIs, and none of them meet my needs). Initially though, I don't think it makes sense to develop for two platforms at once. With that in mind, I have been looking at WPF for Windows and Cocoa for OS X, and they seem similar.
Has anyone had experience porting one to the other? Are there particular techniques/paradigms to follow that will make porting easier? Ignoring business considerations, would you recommend developing on one of them first?
Well. Once you've written an app for Cocoa, it is possible to port it to Windows. This could be done using gnustep or Cocotron.
If you do it the other way, WINE is meant to make porting easier.
I would rather write the OSX version first. This is because Windows users have no clear idea what they want an application to look like. In my experience, they are quite able to suffer through all kinds of user interfaces. Consistency has little value to them. Since there is no common agreement, what a Windows app should look like, nothing stops Windows users from actually liking OSX designs, and they even frequently do. iTunes for windows looks like a very typical OSX app and you hear very few complaints that it would not be enough Windows-ish.
Going the other direction, this is not true. OSX users have a clear preference for Cocoa apps and very little tolerance for, as an example, things like GIMP or Inkscape which work under OSX just as well as anywhere else, but look plainly ugly to the OSX trained eye.
I think that you're on the right path by choosing windowing environments that are specific to each platform. This approach allows you to create a user experience on each platform that isn't restricted by the compromises inherent to cross-platform windowing toolkits.
A good first step is to break your design down into two parts: platform specific and platform neutral elements. You can already put any UI code into the platform specific column, but maybe your app will need some data persistence that can be written in platform-neutral C++. What you may find with this approach is that there is quite a bit of logic and infrastructure that you can write in a platform-neutral way, leaving just the UI and glue code as platform-specific.
There was a recent episode of Late Night Cocoa titled Porting Large Applications to the Mac platform. Your app may not qualify as "large" but this podcast gives quite a bit of great porting knowledge from someone that's done it a few times.
I'm currently working on porting tools in this space and have many years of oft-painful experience in either using or writing cross-platform frameworks on Mac and Windows.
One of the biggest problems in the past has been Apple's refusal to open up the nib format for Cocoa (Carbon nibs were open XML files years ago). That changed with XCode 3 and the .xib format, as well explained by Frasier Speirs.
At the basic layout level, at least, there is now an opportunity to automate porting from one XML format to another. I regard WPF (XAML) as cleaner and so I'm using that as my base format and migrating to Cocoa.
When it comes to the code behind, whilst you can use C# under Mono, the CocoaSharp project seems either stalled or very slow and I wouldn't recommend it.
If you are comfortable with C++, consider having as much logic as possible in C++ with a thin platform-specific layer in C# and Objective-C.
Another approach worth investigating is using a dynamic language like Python or Ruby. I'm not sure which is more mature at present between IronPython and IronRuby but both are now supported by Microsoft people. On the Cocoa side, I think the flexibility of Ruby syntax will triumph and RubyCocoa is probably overtaking PyObjC.
Otherwise, work in C# and Objective-C and maintain two completely independent code bases with identical designs. Fortunately the frameworks have comparable semantics for most things, especially if you make use of bindings.
Well, there is not a straightforward path. The best method is to use something like Model-View-Controller pattern or some other architecture to separate business logic and so forth from the presentation. However, unless you are using Mono, there will be very little code for you to share, I think.If you are developing WPF then you surely doing .NET and, other than Mono, Objective-C is the standard programming tool under Mac OS X.
Keep a good design and you can have most of your code simply be an Objective-C version of your .NET code and vice versa rather than trying to find a migration path.
How is Silverlight going to change the internet in the next 10 years?
Is this going to be a scene changer or just another blip?
People often underestimate Microsoft. I don't know if it's going to change the Internet, but Silverlight will probably become pretty widely used, especially in web-based business applications that require rich interfaces. Flash is good, but being able to develop rich web interfaces with .NET and WPF is much nicer, particularly in that realm.
It will be another blip. It's not seriously cross-platform, unlike Flash or any of its other competition, and no one seems particularly interested in it. It might be neat and shiny but I haven't seen any real reason to move past playing around with it.
Put another way, it's a cool toy but not much else.
Until Silverlight has respectable implementations in other operating systems (read: OS X and Linux) and it can differentiate itself from Flash considerably, it's never going to grab a significant percentage of the rich content web app market, IMO.
I personally think Silverlight will be popular, its got a good "feel" about it IMO as a developer.
The cross-platform issue will be solved soon, as Mono continues to grow fast.
But I think it will be a very long time before anything knocks Flash/Flex off its perch on the top of RIA development platforms.
Silverlight allows the developer to offload some processing to a CLR on the client, using the native language such as C#, provide rich interfaces that are not restricted to HTML/CSS/DOM differences between browsers, and potentially reduce the need for scripting in javascript.
Although I might seem antagonistic here, I really, full heartedly don't like Silverlight, and I don't like Flash either.
They don't bring anything to the table anymore, now that browser are truly fast at rendering and processing. You can do most of the same things with pure Javascript and HTML/CSS. And what you can't do you will be able to do with HTML 5.0. What we need are not more proprietary frameworks, but better tools for what what we already have.
So my guess is 10 years from now, Silverlight and Flash won't be more than wikipedia articles.
I feel that while you can do most of what you need with Javascript and CSS, Silverlight programming feels much more fluid and fast to me. This is especially true when it comes to easily building a rich design with loads of animations. It is very easy for a team of designers and developers to collaborate on Silverlight and WPF projects, and that efficiency is important. Visual Studio being a fantastic IDE has kept many developers on the Microsoft ranch. The Expression suite feels like the next big advancement in allowing your IDE to do a lot of your work for you.
Deep Zoom is another big winner for Silverlight - check out the Silverlight implementation of the Hard Rock Memorabilia collection. Now look at the Flash implementation of SF Moma's art collection.
Don't knock Silverlight until you try it. I am no Microsoft fanboy, but it is very easy to use. People who have never developed using Microsoft technologies don't know the meaning of a good IDE.
I mostly develop with PHP, and I use Aptana for development. VS200x is lightyears ahead of any other IDE in just about everything.
The only real thing standing in the way of Silverlight becoming more widely used is better cross platform support; which would be pretty amazing thing I don't see happening at all. If Microsoft could loosen the reins up a bit, it would do wonders for it. Then again, Microsoft has gotten got at getting certain really good tools out there for free: The Express VS tools, the Dreamspark suite, etc.
One area that Silverlight will catch on is business applications. As architecture models shift into the service oriented realm there will be many companies looking to port their old client/server apps. Silverlight enables them to maintain the rich UI of the forms application while providing the messaging capabilities necessary to talk to the services. Also,t he deployment is wider than what they would get with strictly WPF and xbapps. Flash doesnt really compete in this area and a straight asp.net or other web technology front end, while getting nicer with Ajax and all that fun stuff, wouldnt support the richness you can get out of silverlight.