I'm implementing a GUI program (a cards game) in gtkmm (at the moment). I want that my program runs well at least under Windows and Linux (GTK). Mac OS X would be a plus, although not required. Although I'm using gtkmm, I have some concerns with it.
More concretely:
Lack of support for connecting signals at runtime.
The API for treeview is horrible in the sense that you need to make your own classes
in c++ code every tie you have a new Treemodel.
These two things get a lot in my way when implementing GUI code. My questions are, if I switch to wxwidgets:
1.- Is it possible to connect signals at runtime?
2.- Is the ListCtrl API from Wxwidgets comfortable to use in your opinion?
3.- Is there a decent gui builder (preferably free, but not required) in which I don't have to connect signals by hand in c++ code? This is quite important to keep controller and view code separated.
4.- Is there an alternative to wxwidgets which is better and looks good under gtkmm, besides working on Windows. I'd rather not use qt with its preprocessing step
Thanks in advance.
It is possible.
ListCtrl if just fine to use, and you will maybe find some nicer alternative (UltimateListCtrl, wxGrid...).
wxFormBuilder.
Not that I know of.
Related
I only write QML app with Qt 5.1.1 running on Mac & Windows.
Anyone know what's the version of Qt for Embedded System integrated in the uclinux?
Do the Qt on uclinux support QML? Do I need to re-implement the UI with Qt widgets in C++ to run it on the uclinux?
First and foremost, please do not ask several subquestions in a question.
Anyone know what's the version of Qt for Embedded System integrated in the uclinux?
There is no such a thing. Qt 5 is meant to be well supported for embedded, too, without external third-party projects.
That being said, you may ask Digia about their embedded plans, like Boot2Qt and so on.
Do the Qt on uclinux support QML?
That is the wrong question around. The correct question is whether Qt/QML suppports uclinux. I do not think this will work off-hand, no. You will probably start writing a custom mkspecs file for your scenario and fix lots of issues.
Do I need to re-implement the UI with Qt widgets in C++ to run it on the uclinux?
That would probably be even worse as they are having a lot of overhead in terms additional layer. What I would suggest is to forget about QML for now, and try to bring up a simple screen with QScreen.
As stated, I do not think even that will work off-hand, but if you are enthusiastic, you could get it work.
Since Qt 5 has a hard dependency on the standard library these days, your first task is to get that building againt your mmu-free uclibc. There was some discussion about that here.
But honestly, you may be better off with some lightweight gui framework that supports framebuffer for rendering. Qt is big and not properly tested on minimal systems.
I'm a little new to Qt. I have been programming in C++ for quite a while.
I want to create an application in Qt/C++ just because it's very easy to create the GUIs. I wanted to know that is it possible that I can write a C++ class in native C++ and use it in my Qt application.
I want to write the GUI in Qt and do all processing using my native C++ code rather than Qt/C++. Is it possible to compile a DLL in native C++ and then load and use it in QtC++ application?
I really want to write a GUI application using C++.
There is no such thing as "native C++" as opposed to "Qt/C++", so the question makes little sense. All of core Qt code is compiled native C++, just as any C++ application that uses Qt is.
As JBentley has duly noted:
[You may be] confused because of the code generating tools Qt uses, like moc [or uic]. Those don't mean that C++ compiles natively while Qt doesn't. All those tools do is provide a convenient way to produce a lot of boiler code that the framework relies on, so that the programmer can pretend they don't exist and use things like Qt's slots and signals. The final code which you compile and link is ordinary C++, with calls into the Qt library (also C++) which you've used.
If what you're asking is "am I forced to use Qt classes in all parts of my application", then no - nobody's forcing you to do that. If you already have parts of your application written using boost, or standard C++ library classes, it's fine.
You have to understand that Qt has modular design and provides a lot of non-GUI functionality. You can use the non-gui modules in the non-gui part of your code. It's a fairly clean and general purpose application development framework. It's perfectly fine to use it for various internet server applications, for example.
The following Qt modules are of note for non-gui development:
Core: Core non-graphical classes: containers, event loop, timers, threads, state machines, internationalization, XML, json, file I/O - all of it portable.
Network: Classes to make network programming easier and more portable. Includes secure sockets, HTTP requests, etc.
SQL: Classes for database integration using SQL.
You are able to use any C++ code you would like. I have have actually had questions with the same thought process in my day to day work. First you need to grok the idea that Qt uses normal C++ and special tools to create a robust set of libraries.
Later on come back and you will want to learn more about the items below:
Signals and Slots
This is how events are wired together.
One objects sends a signal and all connected slots get called with the given parameters.
Signals and slots are an example of the Observer Pattern.
Designer Forms
The form designer lets you lay out controls using simple drag and drop operations.
The .ui file gets transformed into C++ code as part of the build process.
Layouts
You can do a lot of things with just the horizontal, vertical and grid layouts
Spacers
You can push things up, down, left, or right using different types of spacers
They look like a spring on the form designer.
Resource Files
Lets you embed graphics and other content directly into the application.
Models, Views and Delegates
Hard to avoid if your have a non trivial UI
There are other things too, but knowledge in these areas will let you make some decent desktop applications. My favorite reference is older, but still a goodie: "C++ GUI Programming with Qt4" http://www.amazon.com/Programming-Edition-Prentice-Software-Development/dp/0132354160
Yes QT4 is "old" and QT5 has been out for some time... but the book provides a solid foundation that you will be able to add information to.
I've been away from GUI programming for quite some time so please pardon my ignorance.
I would like to attempt the following:
Write a Mac OSX app but still be able to port to Win/Linux (i.e. C++ core with Obj-C GUI)
Avoid Qt/other toolkits on OSX (i.e. talk to Cocoa directly - I feel that many Qt apps I use stick out like sore thumbs compared to the rest of my system)
Not as important, but it would be nice to avoid Visual Studio if it means I can have the freedom to use newer C++ features even on Windows if they help create better code.
I believe this configuration might get me what I'm looking for:
Core C++ Static Library
OSX GUI (Cocoa)
Windows GUI (Qt+MinGW?) OR (no new C++ features, Visual Studio + ManagedC++/C#/????)
Linux GUI (Qt)
Once again, sorry for my ignorance but is this possible? Is this sane? Are there any real-world open source examples accomplish something like this?
There is quite a few OS X applications that have completely custom-designed looks that don't use very many stock controls. iStat Menus comes to mind, but there are many other examples. They still look good, but it's done by manually designing them to look good and to "mesh" with the overall look of OS X applications. Even their preferences pane doesn't use stock buttons.
Thus, you can go quite far using Qt, you just have to pay close attention to what you're doing - similarly to the way other developers are paying close attention even when using Cocoa. You'll find that Qt's controls offer functionality often above and beyond what's offered in Cocoa.
That said, on OS X sometimes you may need to run some native code that expects a CFRunLoop to be present. It's good to know that Qt's event loop already spins a runloop for you, so as long as you have an event loop spinning in a given thread, you can use runloop-based code - the default runloop is provided by Qt's implementation of QEventDispatcher (somewhere in its guts). For non-gui threads, the unmodified QThread does it for you. This is useful for using asynchronous IOKit functionality, for example. Another answer of mine presents some Cocoa mouse event grabbing code. A previous version that used Carbon can be found in the edit history of that answer.
Same goes for Windows: Qt runs a message sink for all top-level windows it owns, and you can integrate native controls/windows using qtwinmigrate. You can also integrate ActiveX controls using the Active Qt framework.
Well I think you should try Qt even on OSX. Qt allows native/custom look of applications (those cases you mentioned are probably bad examples - you probably haven't noticed that lots of other applications also use Qt).
Tools I usually use for multi-platform development:
C++ (now C++11 since all major compilers more or less support it)
Boost
Qt
CMake as build system generator
If you use this tool-set you can choose whichever platform you like for development and still be multi-platform without extensive work on the other platforms.
I want to know about developing of gui to vanilla C++ application. I have experience in mostly in command line application. My experience in C++ gui till now is cout and cin. I have some experience in WPF (just to mention that I do have some gui experience) I hope this will describe my level of experience with gui. Now,I want to develop an application which needs separate GUI with possibility of 3D display. Of course, one of the choice for GUI API is Qt.Also,after reading lots of stuff on internet, i think code separation would be really helpful in future.
So, here goes my question: Is it possible if I keep my logic as generic as possible (not using winapi or qt in my logic) and make only GUI part API specific (say winapi or qt). Or I will need to add some code in my logic section, say for synchronization between logic and GUI. One can say signal and slot from qt is possible but as far as i know signals and slots are qt specific. they are not standard C++.
In summery,my question is can i make my logic in standard C++ (to stay platform/ framework independent) and only design platform specific GUI? If yes, could you please suggest a link or tutorial or book. A sample code or implementation would be 'a wish come true'. Also, some insights in code separation tactics would be quite helpful.
Regards!!
EDIT::
I will elaborate my problem. I have an application which has separate GUI and Logic section. The gui uses WinAPI and as the communication mode used is windows messages, previous user has created a HWND object in Logic which communicates to GUI. So, there is a HWND in Logic and HWND in GUI. I don't find this approach satisfying. One of the reason is that Logic part will be edited by non-programmers in later stage (not much. just modification of constants or changing implementation of function without changing para or return value). So, I just want to keep logic part in standard format (as much as possible). So once again, could anyone help me in designing business logic in C++ and GUI in any API.
After reading some threads, I found that answering own question is not a bad practice. So I will share the answer I have got.
There is no standard way to build a C++ gui application without using external dependencies. The synchronization between gui and logic part is always framework specific. So, if I want to develop a C++ gui application, I cannot put logic part in standard C++. It must have some code from external framework which will communicate the logic part and gui part. Having said that, I have found my way in by following method. I am going to put my logic part inside a static lib and then I will attach this lib to gui part. It will increase coding in gui section, but it will keep the base functions in standard c++. This way (a function lib in standard C++ and machine operation in framework specific code) will work for me. I hope I am on right track. :)
You can to a large extent write completely separate logic and GUI code in Qt. However you will be able to create a much more useful GUI if you allow the logic and GUI code to interact. Qt has it's own classes for a lot of things (QString, QVector<> etc.) but you're free to ignore these for the most part and use the standard library instead if you'd prefer.
However, I do not think that it is worth trying to separate Qt from the logic code entirely because, as mentioned before, you will be able to build a much better GUI if they interact. For a simple example you could write a very simple Qt GUI with just a window and a button; press that button and some logic code is run. However with more interaction you could use signals and slots to update a progress bar on the GUI to let the user know how far the logic code had got. Also Qt is very portable, allowing you to build your program for Windows, Mac and at least some Linux distros.
Also for your 3D display requirement I recently found myself trying to do a similar thing and found this example very useful - http://qt-project.org/doc/qt-5.0/qtgui/openglwindow.html.
I think that by default, you should aim to separate business logic from presentation (GUI) code. In web development, the most commonly used pattern is MVC, and it's principles apply equally to native applications.
However, this separation might be more difficult to achieve in native applications. Mainly because there are no frameworks such as Symfony, which have already solved these architectural problems, and make it easy to keep UI and business code separate by following the established conventions. I have't used Qt but from what I know it's mainly a GUI toolkit - models, views and controllers are not as well-defined and integrated.
Depending on the nature of the needed interface, a simple OpenGL GUI might suffice. This is what I did for a simple uni project. The project needed to display a shapefile colored according to statistics in an XML file. I created a number of GUI widgets - button, label etc, and a custom map widget which encapsulates "business logic". Perhaps I should have "cleansed" the map widget, making it as generic as possible, and move all business logic to a separate library, but considering the business layer was very thin I thought the added complexity would outweigh the benefits.
Another factor is your skill-set - current, and areas which you want to improve. I was more interested in OpenGL and freeglut, then in learning Qt. If I had known Qt, I would have used that.
I have done some projects with vanilla C++ and a QT GUI. The idea of not mixing any QT code into the pure C++ stuff is always good but takes a lot of fun out of it. Usually you end up with a much more elaborate GUI than you expected and would often like to connect it better/easier to your code. Signals and Slots are a really great way to let the GUI interact with your code, but then you start mixing...
TLDR: Think really hard about why you don't want to mix your code with e.g. QT. It would not meand mixing GUI and Logic, no way, but your life could be a lot easier using QT classes like QStrings, QProcesses or QThreads...
If you manage to do all the interactions using QTs Signal & Slot mechanism, at some point you might even change you native QT GUI to a QT Quick (QML) one, which is highly customizable, has nice looks and animations and whatnot.
This is just my opinion.
Edit: This question has been answered indirectly in the comments (using GLUT to avoid the need for either) but because its not posted as an answer, I cannot "accept" it although my issue is solved.
I have a cross platform OpenGL application, written in C++, that (on Mac OS X) uses Carbon for the window creation and message pump (Think...NeHe Lesson 1). Recent changes to my code utilizing C++11 features has made it incompatible with the GCC that comes bundled with XCode.
All of my attempts to use systems like MacPorts, HomeBrew, etc... have failed for different reasons (Mostly due to my need to compile 32bit for Carbon support). I was originally going to ask if anyone had a better solution for installing an updated G++ in Mac OS X 10.8.
That seems like a short sighted solution (at some point, I will need to upgrade to Cocoa and 64bit) so my question has evolved to asking what would be the most simple way to have my existing (very large) application utilize Cocoa for this task rather than Carbon?
I have all of the "Carbon Code" in its own separate .cpp/.h file, which has only two functions, one to create an OpenGL window, and one that is a message pump that uses ReceiveNextEvent.
Edit:
To be clearer, I am looking for the best way to design (more or less) a drop in replacement for my existing Carbon window creation, and message pump functions, but in Cocoa. I understand that being a different API, using different language concepts, that a simple one to one command replacement will not suffice. My existing code has a source code file for Mac that has two functions which perform core tasks (with Carbon) that I call, InitWindow, and DoEvents. These create the window, and cycle through the pending events respectively. It is my goal to replace this source code file with one that uses Cocoa, exposing the same functions so there is little to no modification of my core code.
What would be the best way to achieve my goal? I am not familiar with Cocoa and Obj-C is alien to me.
Going to Cocoa 64-bit definitely sounds like a great idea. And I recommend using some of the native UI if you want to make your users happy, too.
The easiest thing to do would be to create an NSWindow with an NSOpenGLView in it. You can either do that in Interface Builder, or in code. It's probably best to do it by creating a new Cocoa app using Xcode's template (File > New Project > Cocoa App). That will give you a window by default. You can open it in Interface Builder and add an NSOpenGLView to it. You can make the view a custom subclass of NSOpenGLView, and add your event handling to it. See the docs for NSResponder for more information on how Cocoa dispatches events.