I'm developing a C++ app using Qt. The app displays some various customized widgets that are made using QML. These widgets renders values using signal/slot system.
I was wondering what could be the best way to manage:
Manage everything in qml files, including rendering and business rules.
Embedding qml files into QWidget class (QQuickWidget) and managing rendering and business rules in c++
When you want to get things up and running fast doing the buisness logic in QML is a good way to go. But things will getting complicated when adding new features. After a while we got a lot of cascade-like callbacks by depending signals-slots in your QML-files. Special when mixing view- and buisness-code in one QML-file will make your code hard to maintain.
To avoid this using some kind of MVC or MVVM-pattern to separate buisness-logic from your view-code makes sence. And of course you can do the buissness-logic in QML. Separation of concerns helps a lot to keep your code-base understandable independent from your programming language.
When you have any performance-concerns regarding your buisness-logic using C++ for it is the best way to go ( made these experiences when starting with a first prototype in QML and needed to port it to an embedded platform ). And you can use C++ for some special QML-Elements as well of course.
So it strongly depends on your problem.
Depends on how complex your core logic is. If it is small and simple, do in QML. Even if it is not that small and simple, there can be quite a lot of benefits to using QML, as prototyping there is much, much faster and easier compared to C++. You don't have to recompile, you don't get crashes but fairly useful error messages. I find QML to be 5 to 10 times faster for prototyping than C++.
You can always move things over to C++ if you want better performance or memory efficiency, and it is a seamless plug and play transition, because you can use signals and slots in both worlds. It is usually faster to develop the algorithms in QML and port to C++ than to do in C++ from scratch. The downside is you have a different toolset on the low level, in C++ you can use Qt's core classes whereas in QML you will have to use JavaScript and its programming idioms. It really depends on how much experience you have with both, but with some practice, it is quite easy to translate QML to C++.
That being said, even if you opt for QML for the logic, it is always a good idea to have it as a separate layer from the GUI.
Unless you need QWidgets for something else, there is absolutely no good reason to use QQuickWidget, thus you can avoid the entire widgets module as a dependency. You do not need widgets to do the core logic in C++.
Related
I recently read an OOP book (Robert Martin I think) that emphasized using a core object that calls interfaces of the things it uses. The point here is that the peripheral objects depend on the core rather than the other way around. This allows better modularity, flexibility, distribution of binaries, build time, etc. Supposedly you can also allow your program to be independent of any particular framework, eg GUI, database, etc. But I'm having a hard time separating the framework from the core.
For example the Qt framework provides class QTreeView; some functions take instances of QAbstractItemModel.
It's conceivable I find or write a different model/view I want to use that is not part of the Qt world, or use some immediate-mode api for the graphics part, etc.
So how do I write my core to be agnostic of Qt entirely?
Do I make up an ITreeView with similar functions as QTreeView, with similar-sounding non-Qt arguments and then delegate to a real QTreeView instance after converting all arguments to real Qt types? It seems silly to recreate so much of the framework just to make it generic.
Or in the real world are people fully absorbed into Qt and it's not realistic to keep it separated?
I know it's possible to write your code in C++ and use Objective C to make native Mac UI and Visual C++ to make native Windows UI.
Can someone please point me to a tutorial or write a sample code that teaches how to do this?
NOTE
I know about Qt or wxWidgets but that isn't the solution I want. I really really want to give a native feeling.
Although you say you know about Qt and wxWidgets, I still recommend you use them. You can do native-feeling apps with them.
You will always have to implement some kind of abstraction layer since the Windows and Mac are vastly different in how their UIs are implemented. You would need to find common patterns, find ways on how to abstract things so that different things can be accessed in a similar way. For this, you need to know both Windows and Mac programming very well. You will spend a lot of time trying to find workarounds and searching bugs. With every new iteration of Windows or Mac OS X, you would need to start working around bugs and/or integrating new behavior yet again.
Using a cross-platform library will save you lots of time and trouble and thus money, if you're writing a commercial application.
Edit: Well, if you're forced to go that route, I'd recommend to do it like this:
Separate the app into two parts: a backend that doesn't know anything about UI which does all the business logic and then the UI part. You would need to implement the UIs completely separate from each other and wouldn't be able to share much code between them. After all, if you would try to find common grounds (for example, if you would like to unify creating and using a button) you could as well use a cross-platform UI library again...
The upside would be that you could use every obscure UI feature available to each OS. The downside would be that you need to maintain two UIs, so if you add a feature to one UI you'd need to reimplement it in the other as well.
But you might want use a cross-platform library for the backend to unify things like file handling, networking and threading.
So I've fooled around with WPF a bit recently, and I must say that I really like the idea. I love the framework as a whole, from the GUI to the plumbing.
However, as much as I love managed land, I love my native code just as much. So I'm wondering what sort of libraries exists for C++ which capture the essence of various parts of WPF. I'm not looking for interop solution, nor do I want Managed C++ or C++/CLI solutions, but pure C++ solutions.
Now, I'm not expecting to find a "copy" of WPF for C++ - I wouldn't expect that to exist, nor would I need it to. Instead, I would expect that different libraries might capture a subset of the desired concepts. My particular interests are
Hardware accelerated graphics for widget based GUI's (via DirectX or OpenGL, preferably the latter)
Declarative language for GUI design (preferably an XML dialect)
Data binding
Resolution independence (less important)
To say a little about my reasoning, I would like to implement such a library myself, which captures a specific model that I have begun working out. I am in the process of finding some more inspiration and helpful resources before locking down my design. The library is intended to be cross-platform, so references to cross-platform ideas would be great, but not strictly necessary as I am usually capable of translating things into cross-platform solutions.
Lastly, although I am writing a C++ library, and C++ ideas would be great, I am open to ideas from any native language.
Thanks in advance for any help.
There isn't really anything like this. Not cross-platform at any rate. Direct2D works reasonably well, but is obviously Windows-only. And NVIDIA recently dropped this "path" extension of OpenGL that is similar in basic functionality, but it is NVIDIA-only (and not available on Mac OSX). Cairo has an OpenGL backend, but I have no idea how good it is. It can't be that good if Mozilla dumped Cairo in favor of D2D on Windows.
Many GUI toolkits have some form of language for making a GUI. Qt has one that is pre-compiled into C++.
Not that I know of. Data binding requires some form of reflection (WPF-style data binding does), and C++ has no native support for reflection. So you would need to implement reflection of some sort before you can even begin to make WPF-style data binding work.
That comes with #1. More or less, as any GPU-based renderer will be able to operate at arbitrary resolutions.
I love C++, but honestly, this sort of thing is best implemented for a higher level language. The lack of language-based reflection support will make implementing data binding a huge pain. Whereas, you could just implement the low-level "render stuff to area" and basic window/event management in C++, then expose it to a scripting language where data binding and such work. That way, you have native code speed where you need it, but the versatility and reflection of a scripting language for dealing with the GUI and its associated data.
I'm several years late, but for the benefit of anybody else reading this question: you're looking for Qt Quick / QML:
http://qt-project.org/doc/qt-4.8/qml-intro.html
http://doc.qt.io/qt-5/qtqml-cppintegration-topic.html
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Gui toolkits, which should I use?
I've got a fair bit of C/C++ experience - mostly for writing console application for Windows/Linux, and also a fair bit of C# experience - generally for writing WinForms applications etc.
I'm extremely impressed with with ease at which I can create a window in .net, for example something as simple as
Form form = new Form();
form.ShowDialog();
is enough to get a blank form up on the screen. In fact,
new Form().ShowDialog();
is technically enough as long as we don't mind losing reference to the form after it's closed.
I've tried writing some windows-based GUI stuff in C++ using windows.h, but not only does the learning curve seem a little steep but also the syntax is extremely verbose. Creating a simple window like the above mentioned single line .net implementation can easily exceed 2 dozen lines using windows.h.
But not only that, if I were to port the application over to Linux/Max (something which I can pretty much never do with .net, with the exception of hacks like mono etc), then I would need to rewrite 95% of the GUI code.
I'm assuming this is where frameworks come in, for example QT etc... (I don't really know much about gui frameworks, I'm afraid).
What GUI frameworks do you recommend? which are the most powerful and which are the easiest to use?
How do you generally tackle the task of coding your GUI in C/C++?
The closer to the metal (so to speak) that you are programming, the more difficult things get. WinForms (provided by the .NET Framework) is a pretty outstanding abstraction over the Win32 API, considering the complexity you've already seen that it involves for the even the simplest of tasks, like getting a window to appear on the screen. All of that is still happening in the background, of course (registering a window class, creating the window, etc.), you just don't have to write the code yourself.
It's interesting that you write off Mono as a "hack", but would consider a library like Qt. I'm really not sure on what basis you make the distinction. The Mono library is widely regarded as excellent when it comes to WinForms support. The biggest detractors are the same as Microsoft's own CLR implementation, namely that it doesn't produce truly native code, which is more irrelevant to performance in the majority of situations than one might think. Beyond that, some complain that Mono applications don't conform fully to the platform's UI guidelines (that is, they don't look and behave exactly like a native application would), but I have a similar complaint about applications written using Qt.
It seems like literally everyone recommends using Qt if you want to do GUI work in C++. As I mentioned above, it happens not to be my favorite library because I'm a stickler for using fully native controls and widgets provided by the platform you're currently running on. I understand that Qt has gotten a little better at this recently, but I still don't think it's up to my standards. If you're more flexible than I am (and I'll warn you that the average Mac user is not any more flexible than I am), and true platform independence is a big concern to you, it's probably the one you should opt for. Many people praise it for its design elegance and convenience, although I seriously doubt that even it offers the same simplicity as the .NET Framework's implementation.
If sheer simplicity and terseness of code is as important as the beginning of your question makes it sound, I highly recommend sticking with C# and WinForms. Things get harder as you start to remove layers of abstraction, and if you don't need the extra levels of control that doing so affords you, there's hardly any justification for making more work for yourself. Mono's Forms implementation is a perfectly viable solution for cross-platform applications, assuming your needs are relatively modest.
Beyond that, if you want to create a truly cross-platform application in C++ the right way, I recommend that you strictly separate your data layer code from your UI layer, and then write the UI using the tools provided by each platform you want to support. In Windows, your options are relatively open: .NET WinForms is a solid choice, native Win32 is a somewhat painful though merited option, and a handful of other libraries like MFC and WxWidgets can help to ease the pain of fully native programming (though not nearly as well as WinForms does). On the Mac, the only real option is Xcode, Interface Builder, and Objective-C, targeting the Cocoa framework. Linux/Unix-based systems are hardly my forte, but I'm given to understand that Qt is about as native a library as you can get. This sounds like more work than I think it is—a well-designed library should handle 80% of the work, leaving only around 20% that you have to do in implementing the UI. Beyond using truly native controls and widgets, I think the other big advantage afforded by this approach is flexibility. Notice how Microsoft Word looks very different (despite some superficial similarities) on Windows than it does on the Mac. And iTunes has become almost a paragon of excellent UI design on the Mac platform, but sticks out like a sore thumb on Windows. On the other hand, if you rolled out something like Windows Media Player on the Mac (and yes, it's been tried by Microsoft themselves, though without much success), Mac users will dismiss it as a complete abomination and probably be somewhat offended that you even tried. Not so good for the truly cross-platform-minded developer. All of that to say, if your app is anything but the simplest of utilities, you'll probably find that an entirely different interface is justified (and even expected) on each platform that you want to support.
No matter how great Qt may be, you're not going to get that with it.
Qt, hands down.
it's the most complete, most mature, fastest framework available. and on top of it, it's seriously multiplaftorm and your choice of commercially friendly open source or paid support.
Does someone know of a book or tutorial explaining Qt for Delphi / C++ Builder / VCL developers?
What would be the best approach for a developer with that background to learn Qt? I'm particulary interested in how to accomplish things that I know how to do in Delphi with Qt.
For example, what is the Qt equivalent to Delphi Frames? What about Forms/Frames inheritance? Should I use Qt Designer, Qt Creator or hand code for such tasks?
Another thing is Qt Widgets and objects life cycle. Does Qt take care of widgets and objects destruction or shoul the programmer do it manually? Or may be Qt does that for some types of objects but not for other types?
As a side note I do know C++, so the language itself is not an issue. I'm concerned with the library.
One way might be to study the source for the FreeCLX open source project. It contains an implementation of the VCL using Qt. So if you are curious which Qt widget maps to a VCL type, that should get you on your way. Note, however, that Qt 2.x.x used multiple inheritance (no longer true in current Qt), so the FreeCLX interfaces to Qt via a special library to flatten this out.
To further what Javier says - concepts from one windowing toolkit to another map even less well than languages. It's especially confusing since there are only so many words (frame,window,widget etc) that get reused.
I would go through the (excellent) examples and tutorials included in the QT distribution (you might have to download the source dist) and then think - how would I have done that in VCL?
the easiest and fastest way to learn something new is to put all the old things aside. don't try to think in Delphi when developing in C++.
first learn some C++ (it's not hard, really) then pick Qt. you don't have to know ALL of C++ and STL to get to speed with Qt, just get comfortable with the syntax and fundamental concepts (like pointers, structs vs. classes, these kind of things).
If I remember correctly, Qt Assistant has some good beginner tutorials, which step you through the basic structure of an increasingly complex Qt GUI app. You also get introduced to the parent/child hierarchy, the signal/slot event system, both of which are key to understanding Qt applications.
I'm with the others who say not to try to map Delphi metaphors to Qt metaphors. However, you will likely find many similarities along the way where your Delphi experience will give you perspective.
Good luck!
EDIT: QtCentre is the best online forum for Qt development in my opinion. You'll find many knowledgeable people there.