Related
yesterday I stumbled across the Haxe NME project, which is a very promising idea. However, it is still not possible to build sophisticated UIs with this framework. In my opinion it seems to be a intimidating task to build a UI framework that targets so many different platforms, hence I think that this isn't a viable approach, because even old and mature UI frameworks like Qt and wxWidgets don't support so many platforms.
However, it could make sense to build a platform specific UI with help of some pretty UI designer tool and then connect the UI code to the UI agnostic code that has been written in Haxe. I don't know if this could work, because I couldn't find any example, but maybe someone who has already written some MVC Haxe code, that could be successfully connected to different platform specific UIs, would like to share his experiences. Thanks.
You say:
However, it is still not possible to build sophisticated UIs
Just because you haven't yet figured out how to do it doesn't mean it's not possible ;)
The reason it is possible is that in the Haxe ecosystem, the language and compiler is extremely consistent cross platform, NME/OpenFL provides a fairly strong cross platform rendering environment (HTML 5 has some quirks, but the others seem fairly strong) and so anything you build on top of these is going to cover a lot of platforms out-of-the-box. It's about being fairly high level - letting the compiler and the libraries take care of the platform quirks.
In MVC, the UI stuff is usually the "View". For View / UI frameworks, check out these libraries:
Stablex UI
NME/OpenFL, Cross Platform. Draws components using NME API. This is
the only one I've played with, but the demo works consistently on android,
flash, html5, native linux. Pretty impressive.
HaxeUI
NME, Cross Platform. Again, draws components on the stage.
Prime
Drawn using Flash API. Not sure if it has been ported cross platform yet.
See also Talk/Video from WWX conference and Slides
Guise
A really innovative way of being able to either draw the UI, or use native if available. Check out the blog post.
Basis
Another attempt at wrapping native components - has iOS and Android libraries so far. Pretty cool, but I haven't played with it yet.
For MVC, there are lots of options:
PrimeVC, mentioned above.
MMVC, based on the RobotLegs framework, but tailored for Haxe.
Lots of small options BBMVC PureMVC etc
The advantage of the MVC frameworks is that they separate your views from your application data (model) and logic (controller). Try to spend some time familiarising yourself with one of the MVC frameworks, and you'll see how you can write your apps in a way where you could use one of these, and then any of the various view engines - either native or NME-rendered. It can be a fairly steep learning curve, but this is how you build apps that are easily portable between different UI frameworks, and easily testable so you know they will scale as the app grows in complexity.
The main problem you seem to face is that there is no out of the box option that is complete and ready for you to use. The multitudes of project people are suggesting do what you want. You need to be willing to use them. A small project on github may be dropped. If so it will be dropped because jo one uses it so its up to people who would like to use it (ie: you) to keep it going.
Everyone can't siphon of others completed projects or nothing would ever be created. Participation is what opensource is about.
Doesn't make sense to have a unified UI for all platforms, every platform have diferent workflow, have you tryed to use a IOS listbox on windows , is simply ridiculous. On the other hand a good design could separate the view from the bussines logic and you can share the bussiness logic with all targets and tweak the views for every target. look at PureMVC
for a mvc example in Haxe
I'm a fairly advanced hobby programmer. I consider myself capable at Objective-C, Java, some straight C, Python, and general MVC design.
I've written quite a few programs but they have all been relatively self-contained, using external libraries occasionally.
When reading about larger projects, and/or more complicated programs, I hear a lot of language thrown around about "Writing one part in X, and writing this part in Y."
Since I have a lack of experience with this, I was wondering if someone could point me in the right direction. What general designs/mechanisms are employed for applications or projects written in more than one language? What is involved in a "scriptable" design?
Thanks for any guidance on the topic!
-Chase
There is no single "right way". A multitude of approaches exist, including the .NET-way, where all the languages are hosted inside a common runtime environment with well-specified interoperability constraints, and a good old Unix-way, where all the components are supposed to communicate via pipes or sockets, using simple text-based protocols.
For the latter you can read a classic book: http://en.wikipedia.org/wiki/The_Unix_Programming_Environment
Depends on what you need to do. For example if you want to build a poker game online then, most probably you would use java for the application and flash/flex for the interface. Java has the power of the libraries and the flash/flex are quite generally available and offer a rich interface.
If you have a software that receives input from an online application and offers output on a specific output (label printer for example) then your online-ready software (Java/PHP/Python) would best communicate with a specially designed program on the target computer. A program for which I'd use C++ for it's technical power, rigurosity and speed compared to java.
The idea is to identify the languages that suit your purpose best. In my opinion it is ideal that you use one language to do all the stuff, that is why I like java as it seems to fit everything although it has a more or less bad renown for slowness.
I see things in a kind of this way:
1. Engineered, machine oriented stuff then it is C++ (and languages of it's kind)
2. Mobile multifunctional stuff (middle-ware mainly) Java
3. Online , browser based stuff PHP especially for B2C(people oriented) applications
4. Python,Ruby etc are from my point of view somewhere between java and PHP but I never really worked with them so I can not give an exact opinion
You can link them together depending on your needs.
Is VCL dead, or does it have a future as a GUI library? As CLX ended, is there any chance for cross-platform support in future releases?
I've had to do some work with legacy app that uses Borland's VCL(BCB6). Now that new features have to be implemented, it's necessary to revalue alternatives. Whether to stick with VCL or migrate to some other library/framework.
I've never read much what's happening in the field Embarcadero(Borland) tools. At least there seems to be only few VCL tagged questions here in SO and no much luck with google either.
Whether to continue using VCL in your project, or migrate to an alternative depends alot on your requirements. The VCL framework is powerful and mature, with lots of 3rd party components, which makes it a good idea to consider. The alternatives have been improving rapidly, and to point out one as the ultimate choice really requires you to carefully consider your requirements, and validate the strengths and weaknesses of the different frameworks.
Considering that cross platform is on the road map, I remind you that so has 64 bit support been for quite a while. We might see cross platform support, perhaps on schedule, perhaps delayed as we have seen with many previous features. I want to believe its coming because I truly like the VCL framework, but I always have a natural doubt concerning the official road map of the RAD studio series - sorry David. ;)
If you've researched the different alternatives, and found VCL to be the best choice based on its relevance to your project, then I'd consider using the VCL framework, especially if it is a framework you are familiar with. Learning a new framework can - while often a good idea - be a time consuming job. So even though there might be a risk of the framework not being held alive (as will there be with any alternatives) you might save a lot of work staying with the familiar framework, if it is the framework that suits your project the most.
If you do consider going with C++ Builder and the VCL, you might find that the C++ Builder Journal is a valuable source of information, they have a relatively quite forum, but with some interesting posts in it, and some free hints on their website: www.bcbjournal.com.
Of course there is also the embarcadero forums, and this site, it may be a good idea to search the Delphi forums and categories, since it seems there are more active users on these, and by far more posts. One good thing though, is that conversion from Delphi to C++ in VCL related questions is quite simple.
VCL is undergoing continued development.
Cross platform is on the current roadmap.
The embarcadero forums are still a valuable resource.
As a user of VCL I must say that your observations are truly correct. VCL might appeal to you, but the resources available compared to QT and other toolkits is poor at least esp. at SO. Our team have also found several bugs in their components, and have more than once patched components to make our application stable. Still for me the main reason to migrate is that VCL locks you in with a single set of development tools. I must admit that I have a hard time trying to find any really good reasons to continue to use it if you have the resources to migrate.
Given that bcc32 and its libraries is also very buggy, the lockin gets even more serious, The last months me and my team have spent more time fixing issues caused by the compiler than actually developing features. For me this is such a serious impediment that its cost overweight its benefits tenfold. Unfortunately the costs of migrating for us is so high that we at least for now have to endure its pains.
I'm now with a idea to start the development of a bare bones Qt/GTK+-like framework, but I want to know some things before I start the creation of this project:
What is the structure of GTK+ and Qt?
Do I need to develop a window manager to build my own framework?
Some resources to start?
Developing a GUI/Application framework is a significant undertaking. You might want to be very clear about why you need to write yet an other framework.
Both projects you mention are open source. Why not start there?
GTK: git clone git://git.gnome.org/gtk+
Qt: git clone git://gitorious.org/qt/qt.git
Ed You ask what the structure of GTK and Qt are, whether you need to write your own widow manager (answer: no) and how to get started. Answers to at least the first two are in the source code. Don't forget, great practitioners in any field learn by watching others. Reading code is no different.
Writing a GUI/app framework would be a great learning experience, but even a fairly small app framework would be a very big job, and not something you really should tackle until you're fairly expert in writing applications using several other frameworks and widget toolkits.
I did something like this once, back in the early years of this decade. That was after I'd been programming for the Mac for over 15 years, Windows over 10, and had programmed both directly to their native graphics, event, and widget APIs, as well as various object-oriented toolkits for them including PowerPlant, MFC, and MacApp. When I started working on a PalmOS application, I spent a couple of weeks writing a very small app framework modeled on PowerPlant. But I could not have succeeded at all without those decades of broad and deep experience with so many GUI systems.
Doing this for Linux/X11 is even more work. That's because, unlike Mac OS and Windows, neither X11 nor Linux supply built-in user interface widgets, or much in the way of graphics primitives or text layout capabilities. GTK+ is part of the GNOME ecosystem; it provides the widgets, gets its message queue and internal communications from GObject, relies on GDK to abstract and simplify its graphics and event communications with X11, and uses Pango and Cairo for text rendering and layout. I work all through that system, and it probably represents many dozens of person-years of hard work by a lot of really smart people. And I'm sure Qt is very similar.
So if you really want to do this, I would recommend you:
Write programs with a lot of different app and widget toolkits, on multiple operating systems. That will help you learn not just how such systems work, but why they are designed as they are. And it will give you some feeling for what works well, and what works poorly.
Contribute bug fixes or new features to one or more of the various open-source frameworks. GTK+ has a list of tasks for beginners to work on. Another great open-source framework is wxWidgets.
Become an expert-level C/C++ programmer.
When you've done that for a few years, you will have the expertise suitable for tackling your own framework.
That sounds like a major undertaking, at least as a starting project.
Not sure what you mean by "the structure" of e.g. GTK+. You can see the object hierarchy for GTK+, that tells you at least how the implemented objects (GTK+ is an object-oriented API) relate to each other. You can guess how the code can be structured, from that information.
And no, you don't need to write your own window manager; the toolkits mainly concern themselves with what happens inside windows, not with the window management itself. Of course you could decide that your "platform" should have a wider scope, and include a WM.
I think some of the answers here might exaggerate a bit. Obviously making something of the same quality, width and depth as Qt and Gtk is a huge untertaking. But you can make simpler stuff and still learn a lot about how it works. I suggest doing like I did in university. Use OpenGL with Glut. Then you got basic drawing functionality and event system in place already. You then need to create classes for buttons, text fields etc.
If you want to make it really simple then each component just needs to know where it is drawn and have some sort of bounding box where you check whether mouse click are inside or not. You also needs to create some system which makes it possible for buttons, check boxes etc to tell the rest of your code that they were clicked.
This isn't really the rocket science people here make it out to be. Games have made their own very simple GUI toolkits for years. You can try that approach as well. I have modeled a simple GUI tookit on top of a game engine before. Your buttons and textfield could be simply be sprites.
But yeah, if you want to make something that will compete with Gtk+ and Qt, forget about it. That is a team effort over many years.
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 5 years ago.
Improve this question
I have experience writing console and network client/server applications in C and C++, but I know next to nothing about using the win32 visual API, MFC, Qt, wxWidgets, etc. Where is a good place to start, and what method should I specialize in, so as to be future ready and robust?
This is a rather broad question, as programming GUI applications in Windows can be done in so many ways.
There are two main parts to developing any GUI app: the language and the API/framework. Considering you're interested in learning to build Windows GUI apps, the language isn't really a point of focus for you. Hence, you should pick a language you already know and work with a framework or API that can be harnessed by your chosen language.
If you want to use C you're pretty much restricted to dealing with the Win32 API yourself, in which case reading Petzold or Richter would be great places to start. The Win32 API can be quite daunting, but it's well worth the effort to learn (imho). There are plenty of tutorials on Win32 on the web, and there's always MSDN, with a complete reference/guide to the Win32 API. Make sure you cover not just the API, but other areas such as resources/dialogs as they are building blocks for your Win32 application.
If you want to use C++ you have all of the options that you have when using C plus a few others. I'd recommend going with the Win32 API directly, and then moving on to a known framework such as MFC, Qt, wxWindows or GTK so that you can spend less time working with boilerplate code and instead focus on writing your application logic. The last 3 options I just listed have the added benefit of being cross-platform, so you don't have to worry too much about platform-specific issues. Given that you said you want to work with Windows, I'll assume you're keen to focus on that rather than cross-platform -- so go with MFC, but spend some time with the Win32 API first to get familiar with some of the concepts.
When dealing with MFC and the Win32 API, it's a good idea to try and get a solid understanding of the terminology prior to writing code. For example, you need to understand what the message pump is, and how it works. You need to know about concepts such as "owner-drawn controls", and subclassing. When you understand these things (and more), you'll find it easier to work with MFC because it uses similar terminology in its class interfaces (eg. you need to know what "translate messages" means before you can understand how and when to use PreTranslateMessage).
You could also use Managed C++ to write .NET GUI applications, but I've read in a few places that Managed C++ wasn't really intended to be used in this manner. Instead it should be used as a gateway between native/unmanaged code and managed code. If you're using .NET it's best to use a .NET language such as VB.NET or C# to build your GUIs.
So if you are going to use .NET, you currently have the choice of the WinForms library, or WPF. I personally feel that you'd be wasting time learning to build WinForms applications given that WPF is designed to replace it. Over time WPF will become more prevelant and Winforms will most likely die off. WPF has a much richer API set, and doesn't suffer from many of the limitations that Winforms does. If you do choose this route, however, you'll no doubt have to learn XAML, which is a markup language that drives WPF applications. This technology is coming of age, and there are many great places to learn about it. First, there are sites such as LearnWPF, and DrWPF which have some really great articles. Secondly, there are plenty of quality books on the topic.
So, to sum up, once you've picked your language and tech, the path is actually quite easy. Just pick up a book or two, read some blogs, get into some code samples.. and most importantly ... write code. Keep writing, keep making mistakes, and keep learning from them.
As a final note...
In other words, Silverlight. If you don't want to go the MS route you might give Adobe's Flash/Flex a look see. Both Silverlight and Flash/Flex build RIA's. Which I think is where we are headed. They days of Office like apps are numbered
I don't agree at all. Silverlight is not the same as WPF. Silverlight is web-specific, and only has a subset of WPF's features. Given that the question asks for Windows GUI apps, Flash/Flex Rich Internet Apps are not really a fitting suggestion. I also don't agree that the days of Rich Client Applications (such as office) are numbered at all.
I hope that helps. Good luck :)
I don't know if I'd call it a good place to start, but if you want to be future ready, take a look at the windows presentation foundation which is built entirely for the purpose of programming GUI's for windows
My first experience writing simple GUI applications for Windows was with C# and Visual Studio. The GUI-building interface is a simple drag and drop deal that generates skeleton methods based on potential user actions. I only did fairly basic programming with this, but I imagine it would be an excellent place to start to learn the basics and extend into the more advanced capabilities as you go.
There are plenty of online Win32 tutorials:
http://www.zeusedit.com/forum/viewtopic.php?t=1218
There are plenty of compilers to choose from:
http://www.zeusedit.com/forum/viewtopic.php?t=238
I would also recommend getting the Borland Win32 SDK documentation in WinHelp file format:
http://www.zeusedit.com/forum/viewtopic.php?t=7
It only covers the bare basics of the Win32, but when starting, this can be helpful as it is less daunting and less bloated than the MSDN.
I'd never go down the Silverlight, Flash/Flex or any similar route. It does look nice, but the main problem is that the code of the engine that runs it is completely closed-box and controlled by a single company. Take, for example 64bit versions of both of those. If some new platform emerges, you won't be able to migrate your existing code to it.
For business apps, Windows Forms is very mature. It provides a gentle path from auto-generating a lot for you into allowing fine-grained control and rolling your own. There are tons of high-quality third party controls and a large body of examples, docs, etc out there. It's hard to run into a problem that someone else hasn't solved. I highly recommend acquiring some background Win32 knowledge (e.g. Petzold) as the WinForms framework lives on top of it.
I have no WPF experience, but from the sample apps I've seen it looks like a good choice for apps whose interfaces would benefit from more graphical metaphors. So if you're doing a banking app, probably not worth the extra design overhead. But if you're doing, say, a warehouse management app it could be improved by dropping pretty boxes into pretty bins.
#StephenCox: wrong answer to the wrong question. OP is asking about desktop client apps, and moreover, WPF != Silverlight.
For a simple starting point to get your head around the "event-driven" nature basically all frameworks are created around look at FLTK.
Here are some quick starting videos Link
For professional use I'd recommend Qt, expensive but often worth it in commercial situations.
Since you are already familiar with C and C++ I would recommend learning how to write a simple Windows GUI app using Charles Petzold's book. It will give you the fundamental understanding of how Windows works. It's good to understand that most everything that you see is a window (a button is a window for example) and that these windows respond to messages. I wouldnt' spend a lot of time on this though and you don't necessarily need to do this first if you are going to chose WPF. I just think it's good to have a basic understanding of this.
There was a good podcast recently on .Net Rocks called "Kate Gregory Develops in C++ for Vista!" on there she recommends that someone starting out now should not use/learn MFC (even though it has been recently updated).
As far as getting ready for the future you need to learn WPF, but it isn't complete yet, so depending on the kinds of client side apps you want to create, you will probably need to learn WinForms. The majority of people aren't using WPF yet, so it's a good time to start learning. I think you will find it easier using C# to learn it instead of doing managed code with C++.
Get your basics right first. Best tutorial I've found is: http://winprog.org/tutorial/start.html
After that, although the homepage is hatefully distasteful, the tutorial pages are good in content and aesthetics: http://www.tenouk.com/cplusmfcdotnet.html
Then of course there's MSDN.