I have recently read MFC Internals (ISBN 9780201407211) and it helped me greatly gain an intimate understanding of how MFC works and increased productivity about 100 fold. I was wondering now that I am into Qt, is there any book or documentation out there like this? I have been having a hard time finding straight-up documentation on Qt, it always seems to be beat-around=the-bush style of documentation (they tell you how to build the house, but not how to cut down the tree) ??
The best way is to try developing your own application. Just start from a basic application like calculator. Add a few widgets to it and code it as you go. For reference use "C++ gui programming with Qt4" mentioned by Zlatomir. I have recently designed a whole GUI using Qt. I drew its screenshots on Inkscape to get a prototype look and afterwards I started working on designer to fulfill each functionality. Then I implemented the code and I repeated the designing and coding steps. Also, the best help will be Qt Assistant - its sufficiently complete, no Internet required so save times and simple to use. Going my way, you will not only learn Qt in short interval after which you can go through the book to know what tips and tricks you might not know, but also it will be interesting so that you may not give up like many others who just fall midway through the reading part. Warning - Doing this way, you will also know about pitfalls/drawbacks of Qt and how to not go that way.
This is one of the links I found last night. I went through 2 pages and found it might make your life a bit easier - http://zetcode.com/gui/qt4/
I have not read the MFC book you mentioned, but the Qt framework i learned by reading from "C++ gui programming with Qt4" (the first edition is available as a free download) and "Foundation of Qt development" and also it's worth mentioning this documentation page, that contains links to the basic concepts of Qt framework.
Related
I'm developing my first Windows desktop application and I'm trying to figure out what the best approach would be to create the program's GUI.
I know, I know... I feel stupid for asking considering the amount of data on the subject on SO. However most answers seem outdated and I'm not sure if they fit my specific project. Also tutorials for Windows 8 'metro apps' are clogging my Google search results, which is NOT what I'm looking for.
I use Visual Studio. I've followed tutorials. I have basic knowledge of C and Java and extensive experience with PHP. I'm excited to learn C++, so I'm not looking for GUIs to create a GUI (like WinForms). I also don't care about managed code and portability for now, especially since I'm trying to avoid dependencies (i.e. users having to install .NET). As long as it runs smoothly on Vista and up, I'm happy.
The application
The software will teach basic physics to kids. I'd like to create a main area and a sidebar. The main area will feature a physics animation, say a bouncing ball, along with some Q&A. Users can zoom in to the animation to measure some stuff and answer the question. Users can track their progress in the sidebar. That's pretty much it.
What I've found so far
I'm getting a bit frustrated with MSDN. Most of their examples are given in four different languages (C#, C++, etc). I can't seem to get more than a bit of Hello World code from them.
I found a GDI API on MSDN and it seems like a good start for me. However I've read quite a few answers on SO saying creating layouts in pure C++ is really hard, that we're better of using frameworks like ATL and WTL. Since I'm also going to create (somewhat interactive) animations, I've wondered whether I should use gaming-targeted APIs like Direct2D.
Since all of this is new to me, and there are a lot of options, I don't know where to start for my particular application. Any tips would be greatly appreciated!
Using the raw Win32 API (no additional downloads or third-party helpers):
Here's a good primer (introduces dialog boxes, text boxes, buttons, etc): theForger's Win32 API Tutorial
And here's where you go from there (numeric up-downs, list boxes, combo boxes, tooltips, and more): Common Controls on MSDN. Most of these require you to #include <commctrl.h>.
I also found this to be a good resource that covered what the other two didn't: Win32 Developer - Window Assets
But the Win32 API doesn't seem like it does exactly what you want. A physics app for kids should have a more visual GUI than the API can provide. Good luck, though!
If you're ok with adding additional Frameworks, I'd suggest looking at Qt.
It allows to create the GUI from code only, has a good structure, and has an Interface for 2D drawing, if required.
If you are concerned about dependencies, you only have to include the Qt DLLs to your executables; no installation is required for the user.
To get started, see my (old) tutorial "Lessons in Windows API Programming".
But you really need a good book, such as edition 5 or earlier of Charles Petzold's classic "Programming Windows".
The problem with latest edition is that it's for C# and .NET, with Charles grabbing the tail of the "new way" at just the wrong time…
Disclaimer: I haven't checked the details of edition numbers.
Using the Windows API is the simplest, but producing advanced GUIs can take a very long time. Microsoft Foundation Class is a way to make the Windows API more user friendly and OOP. Does anyone have any experience with MFC?
Why not use some 2D C++ game engine, like HGE: http://hge.relishgames.com/overview.html.
This is my first time asking here but I've been a reader for ages! A fantastic place to learn!
I was asked to design a simple board game as a programming project this semester (using C++) and to implement GUI for a bonus mark. I was rather lost reading through tens of possible GUI toolkits and not knowing which one to use. I'm rather a beginner and this is my first big project!
My requirements for GUI are very very basic. All I want is to allow the user to pick from between two options at the start of the game. Those options determine which character the user will pick in the game to play with. This is the only input I want from the user. The console program would receive this input, interpret it and do all the logic of the game in the console window.
Currently, the console window displays a numbered list of options for the user who then picks a number and based off that character input, the console knows what to do through some if-statements.
Up till now, I've been told that GTK+ is a good option and I've been advised to check out wxWidgets and QT4. I'm confused on which one to use since I want something fast to learn and simple to implement because the purpose I want it for is also simple. I was also rather reluctant to start learning a GUI toolkit from its basics then realizing it might not have my simple requirement.
Thank you in advance fellas and sorry for the rather long post!
If you want something pretty basic as far as a GUI goes, it might be worth looking into some sample applications from any of the named projects. See what you can find in a sample application that is most similar to what you have, and try to get that working. Then once you have it working, and tweaked to your liking, maybe play around with things a bit more then for a further/better understanding.
My previous experience is with WxWidgets and Qt. My advice would be to check out Qt because of the great documentation for the project as well as the QAssistant.
Good Luck, GUIs can be really fun to incrementally learn!
For my school project, I would like to build a gui that someone else can use to create a gui. Upon some research I saw lot of gui builders but didn't see anything along the lines of what I am looking for.
But then I did find a tutorial using C# on here
I rather create this gui editor for linux environment.
Any suggestions to where I should start? what tools I can use? Any links to any tutorials?
Any help/direction would be greatly appreciated.
P.S. I would like to add that it only needs to be very simple. like few text input fields and some button type fields that user can arrange in the order desired.
I would recommend that you not try to build your own GUI builder. It is a daunting task that you will not be able to accomplish as a school project. C++ is fully-compiled, which means that it lacks almost every feature that enables people to build meta-tools (like GUI editors) for it. This mainly has to do with the fact that C++ does not have runtime reflection (natively, anyway). Beyond that, there is no "one GUI toolkit and/or paradigm to rule them all." This makes your problem incredibly difficult to deal with.
So: I would recommend Qt, because it works on a ton of platforms, is easy to use and is just plain awesome. You could also look at the billions of other GUI toolkits like Gtk+, Tk, FLTK, YAAF, GLUI, dlib, CLX...
I'm aware that this does not actually answer the question. However, I do not think that the author is aware of how incredibly difficult the task he has set in front of himself is.
I would recommend starting by implementing it like an interpreter. Start with a very simple command line tool that takes commands like window(300, 400, "window1") and button(50,100, "button1") etc and output the code (native or whatever other GUI code you want), to a file. The goal should be to output a file that can be run and show the GUI that was designed. Once you have that, build a GUI that uses the command line functions as a back-end.
I don't have any exact links to this, but here's an example of what you could do. Gtk has the option of loading a GUI by using a class called GtkBuilder. Glade (the usual Gtk gui editor) has support for outputting it's result as an XML file that the GtkBuilder class then reads.
It would be possible for your program to output an equivalently formed XML file that GtkBuilder could read.
I have no clue as to how difficult it would be to target that XML though.
You should use GTK+ or Qt if you are targeting the linux environment. I think the first step is to learn how to program gui, which takes some time considering you are writing c/c++ code wich is different from higher level languages. Don't you think learning to code gui programs and writing a gui builder at the same time is a little bit too much.? First you should master the basics about gui and then go on to harder projects.
Here's a link to an excellent book on gtk. (Foundations of gtk+ development - Andrew Krause)
http://books.google.com/books?id=L1BZZYRrqSgC&printsec=frontcover&dq=foundations+krause&hl=es&cd=1#v=onepage&q=&f=false
And here's a great tutorial/cookbook for gtk+.
http://zetcode.com/tutorials/gtktutorial/
The official documentation is on library.gnome.org
My final advice is learn one thing at a time.
I used to program in Qt3 a long time ago and I had read a great book that I still have by O'reilly on Qt3. I wanted to start using Qt4 again now several years later.
Can I use my Qt3 book to get up to speed again, or has things changed so much that I should buy a Qt4 book?
In a nutshell:
Qt 4 is (even) better -- and more powerful and flexible -- than Qt 3
you'll be fine!
The Porting to Qt 4 documentation gives some idea of the many small changes to APIs.
What's New in Qt 4 gives an overview of the big differences between Qt 3 and Qt 4.
Some major changes that noone has mentioned so far:
Model/View architecture
template container classes
a new, modular build system
a new action-based main window implementation
widget styling with CSS
ports for S60 and other platforms
There are also lots of small fixes, improvements and useful new classes such as QFormLayout and QSignalSpy.
You should consult the Qt books page at Nokia.
Two books from that page are available freely:
C++ GUI Programming with Qt 4 (first edition) by Jasmin Blanchette and Mark Summerfield
An Introduction to Design Patterns in C++ with Qt 4 by Alan Ezust, Paul Ezust
Qt3 support classes still exist in Qt4 but Qt has developed itself very much. I think using your Qt3 book will slow you down. It is best if you buy a new book.
If you don't want to spend money on a book, examples, tutorials & documentations are very helpful.
You can find a 3 to 4 guidelines document with all the differences on Nokia's site.
I would recommend a Qt 4 book to a Qt 3 one, but since you have already worked with Qt, I think that you can just use the docs and be ok.
Most of the things remain quite similar. There was some cleanup, but the basics (signal-slot mechanism for example) remain the same. You still have all those QStrings, QActions, QDialogs etc. Your Qt3 knowledge should remain valuable.
On the other hand there are many new elements. There's a big QGraphicsView framework, Phonon framework for multimedia files, QtWebKit HTML engine, QtConcurrent engine for multithreading etc. You might want to learn all the new goodies.
Trolltech (what's the current name?) always has good documentation, so check What's new in Qt4 and you should be fine with API reference for the latest Qt4 version.
If you know Qt, this
http://qt.nokia.com/doc/4.5/classes.html
should be okay to get adapted.
For redirection to documentation for the latest version of Qt use one of the following links: http://doc.trolltech.com/latest/ or http://qt.nokia.com/doc/latest/
I say you use the designer for a while and look at the generated code. I used it to learn how to work with Qt4.
Qt4 is much more powerful than Qt3 ever was (especially now, as Qt 4.6 draws near, even though Qt 4.0 had some shortcomings). Your knowledge of Qt3 will let you do basic stuff with Qt4 as the style hasn't changed much for basic functionality, but to truly use all the power of Qt4, you will need to learn things that are Qt4 specific.
We currently maintain a suit of MFC applications that are fairly well designed, however the user interface is beginning to look tired and a lot of the code is in need quite a bit of refactoring to tidy up some duplication and/or performance problems. We make use of quite a few custom controls that handle all their own drawing (all written using MFC).
Recently I've been doing more research into Qt and the benefits it provides (cross-platform and supports what you might call a more "professional" looking framework for UI development).
My question is - what would be the best approach to perhaps moving to the Qt framework? Does Qt play nice with MFC? Would it be better to start porting some of our custom controls to Qt and gradually integrate more and more into our existing MFC apps? (is this possible?).
Any advice or previous experience is appreciated.
In my company, we are currently using Qt and are very happy with it.
I personnally never had to move a MFC-app into using the Qt framework, but here is something which might be of some interest for you :
Qt/MFC Migration Framework
Qt/MFC Migration Framework
It's part of Qt-Solutions, so this means you'll have to buy a Qt license along with a Qt-Solutions license. (edit: not any more)
I hope this helps !
(This doesn't really answer your specific questions but...)
I haven't personally used Qt, but it's not free for commercial Windows development.
Have you looked at wxWindows which is free? Nice article here. Just as an aside, if you wanted a single code base for all platforms, then you may have to migrate away from MFC - I am pretty sure (someone will correct if wrong) that MFC only targets Windows.
One other option would be to look at the Feature Pack update to MFC in SP1 of VS2008 - it includes access to new controls, including the Office style ribbon controls.
It's a tricky problem, and I suspect that the answer depends on how much time you have. You will get a much better result if you port your custom controls to Qt - if you use the QStyle classes to do the actual drawing then you'll end up with theme-able code right out of the box.
In general, my advice would be to bite the bullet and go the whole way at once. Sure, it might take longer, but the alternative is to spend an age trying to debug code that doesn't quite play ball, and end up writing more code to deal with minor incompatibilities between the two systems (been there, done that).
So, to summarise, my advice is to start a branch and rip out all your old MFC code and replace it with Qt. You'll get platform independence (almost) for free, and while it will take a while, you'll end up with a much nicer product at the end of it.
One final word of warning: make sure you take the time to understand the "Qt way of doing things" - in some cases it can be quite different to the MFC approach - the last thing you want to do is to end up with MFC-style Qt code.
I have lead a team doing this kind of thing before (not MFC to QT but the principles should work).
First we documented the dialogs and what their inputs, controls and outputs were. Also, we create several test cases especially for any clever logic inside the GUI.
Sometimes we had to refactor some business logic to provide a clean interface the GUIs but this is the way it should have been done in the first place tbh.
Now we had a list of GUIs, inputs, outputs, tests and an interface that the encapsulated GUI had to match.
We began, project by project, to create equivilant GUIs to the old ones. Once we did that we could slot the GUI in where the old one was, rebuild and test it. At first we tripped a lot but we soon worked out the common errors and fixed them. We navigated (I think) 612 dialogs although there was a team of about a dozen of us working on it.