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 6 years ago.
Improve this question
Nokia has just introduced Qt Quick (build UI declaratively like using CSS/HTML) in the recent beta versions of Qt, check this example page, it can build fancy and modern UI, very cool!
On the opposite, the UI developed by 'traditional Qt' seems to be less fancy (I might be wrong, see disclaimer below).
So my question is, would you use 'Traditional Qt' or 'Qt Quick' for a new desktop program? Why?
My initial thoughts:
'Traditional Qt':
Pros:
The overall technologies used be less, thus simpler, if you use PySide, you only code in Python, don't have to mess with the CSS/JS-like things in Qt Quick;
It's maturer.
Cons:
Building fancy UI seems to be more difficult?
'Qt Quick':
Pros and cons: the other way around.
Edit: Qt Quick has a downside, correct me if I'm wrong, you can't design Qt Quick UI in a WYSIWYG way, right?
Disclaimer: I'm new to Qt, PySide and Python, just recently has started evaluating using these tech to build desktop programs.
ave been messing up with qml for my desktop and i personally found this:
its easier to create animations than in traditional qt/c++/pyqt (i loved the animations :)
I haven't looked through all examples but the code size of qml apps looks smaller than equivalent apps in c++
Problems i have found with qml
has poor qml design support- at the moment custom elements dont show up in qml designer.This is a big pain coz ideally i should get a designer to create my ui and i concentrate on the code. Their qml designer still needs some work
You are expected to learn javascript since its the "recommended" way of scripting in qt. Javascript is NOT easy as you may expect eg learning python took me a few hours but javascript looks superficially similar to c but some of its concepts are different. Also i wonder if i can protect intellectual property in an app written i just javascript and qml.(correct me if am wrong)
native widgets are not available in qml eg it just offers rectangles, etc which you combine to form your own widgets.
This has not stopped me from playing with qml and as it matures, i shall adopt a wait and see attitude. Currently am using qml for part of my ui and c++ for the backend.
You made one mistake: Qt Quick is not available only in a beta version of Qt. It has been part of the official Qt release since 4.7 (although each minor version significantly improved the features offered by Qt Quick).
Although the "normal" Qt UI (with QWidgets and layouts and all) is older, this doesn't necessarily mean Qt Quick is immature. It is part of the release, after all.
One thing you fail to point out in your pro's and cons is performance: "normal" Qt UI's are prebuillt (for the most part, basically), and Qt Quick UI's rely on runtime interpretation of QML and CSS/HTML as you say. This will mostly not impact application speed on a desktop system, but if you run into performance bottleneck because you're making the UI too fancy, don't say I didn't warn you. Although such a bottleneck probably means you should've gone OpenGL from the beginning.
Qt Quick provides an easy way of building a cool UI (that's the selling point anyway) and will allow you to use cooler effects in an easier way than the old stuff.
If you are using Python then you probably are not concerned about performance. Traditional Qt allows for fancy looks, too via QSS. What Qt Quick gives is a way to easily build a UI (even without tooling support that is being introduced in 4.8) and use scripting to make it work.
You can make fancy UIs with tradtional Qt, too, mainly via QSS and deriving existing widgets. Most Qt examples don't focus on this but that doesn't mean it can't be done. It also probably gives a better overall performance, especially if coded in C++.
I would use traditional Qt because I'm more familiar with it. But this is subjective anyway, so I think your question will be closed.
I have not so experience on traditional Qt UI systems. But I can give you my experience on QtQuick:
UI using QML is more simple.
QML enables you to better developing using MVC pattern. It makes View separated from Model. You can load different version of the UI in runtime.
QML enables developing advanced UI.
It is very performant now (using QSceneGraph technology). It is implemented on multiple UI threads! I am not sure that you can make more performant UI using C++ anymore!
UI designers can develop UI simpler than HTML+CSS+Javascript!
You can develop your custom UI element by C++ using specific classes.
QML is based on OpenGL and in free version of Qt you need to notice that.
QML has a specific debugger and profiler. Debugging in UI is so easy.
If you want to develop your app using a standard patten like MVC, QML may be more suitable.
You need to be careful about performance notes.
Related
the QT widget is very time consuming in terms of UI development, my CSS sheets has 3000 lines of code already and it is very time consuming to do UI changes. My application is very demanding in terms of performance, I was thinking of embedding the widgets into QML to have easier and faster control of the UI but I'm really worried about performance, will worth the try or it is just bad practice?
My application is very demanding in terms of performance, I was
thinking of embedding the widgets into QML to have easier and faster
control of the UI but I'm really worried about performance, will worth
the try or it is just bad practice?
Since Qt 5.1 we can easily embed QML view to Qt Widget container. There is a blog I stumbled upon some time ago: Combining Qt Widgets and QML with QWidget::createWindowContainer().
As for performance, unsure what kind of performance is in demand for your application? Overall QML renders to screen via OpenGL or very fast. On the other hand with QML you often need to deal with JavaScript which of course is not comparable to C++. There is Qt Quick Compiler introduced to commercial Qt, though.
As for QWidget-based UI vs. QML: the discussion can be considered an expression of opinion etc. Some consideration points then:
Developing and maintaining one kind of UI, either widget or QML based is easier.
Hybrid UI is possible but it makes sense to understand what you can gain from it.
Most desktop apps are fully satisfied with widgets only.
When the app supposed to be ported to mobile platforms as well then QML makes more sense.
When the app supposed to rely on 'touch' then QML is also more beneficial than widgets.
the QT widget is very time consuming in terms of UI development, my
CSS sheets has 3000 lines of code already and it is very time
consuming to do UI changes.
Hmm... very heavily styled widget-based app? I can only be sure that these two concepts: widgets and QML are very different but both widget stylesheets and QML are declarative language though different. I am also sure that any serious app needs more of C++ and with QML we need to spend time bridging C++ code with QML.
And the distribution of QML apps can also be a bit more complex than purely widget-based: for instance you need to customized Qt build to support OpenGL emulated for certain VMs and platforms: that is one interesting topic. Also with Qt Quick widgets you use should put them either to resource distributed with the app or you need Qt Quick Compiler. And if you use it, be sure that all QML code was compiled by it and no part of the app still uses 'scripted' QML which is missing from resources. I made use of Qt 5.5 Quick Compiler in our app and found not only quite a few bugs with it but also still needs to drag certain Qt Quick files from framework together with the app install package. That is not as bad with standard dynamic link and windeployqt tool. But a serious app often needs to be statically linked with all its dependencies and then we cannot use windeployqt tool.
Overall Qt is departing from widgets to QML but what can we gain and how much we need QML in our real applications is a long discussion.
New to Qt. In the official Qt tutorial, it says:
To set up a project, you first have to decide what kind of an application you want to develop: do you want a user interface based on Qt Quick or HTML5 or Qt widgets.
We plan to use Qt to do medical image display, and also use Qt to build a GUI application to control a medical device. They will be two different projects.
Which Qt project type we should use for them?
Docs say:
QWidgets are a better choice if your UI is comprised of a small number of complex and static elements, and QML is a better choice if your UI is comprised of a large number of simple and dynamic elements.
I say:
If you're going for desktop applications I'd suggest Qt Widgets, you don't have to ship the final app with libs for QML and the whole source will be written in C++ (faster, simplier so easier to debug).
QML would be a nice alternative if you want to create phone/tablet (touch experience in general).
I would argue that between Qt Quick and Qt Widgets there is no objectively right answer. In theory, one should be able to replicate any UI using either method - because at the end of the day, they are both using QtGui behind the scenes. So functionality is probably not an issue.
One thing to note is that Qt Quick (i.e., QML) is designed explicitly to make UI programming require much less code, and much less C++ knowledge. I would say it achieves this goal very well.
However, at the end of the day, I think it mostly comes down to what language your developers are already familiar with. If you have a team of C++ pro's, then I would go with Qt Widgets - if only because it's going to be very easy for them to pick up, and it's something they're already familiar with. (I'm guessing this is the case because you're already writing C++ code for your project).
If, on the other hand, your developers are already very good at QML (or, more generally, JavaScript - which QML is heavily influenced by), then I would go with Qt Quick for the same reasons.
I know of two types of Qt UI: Qt Quick and widgets.
Widgets behave like most other UI toolkits out there, you have a GUI editor and a tree of UI objects. They are pretty mature and look like most standard UIs.
Qt Quick is the newer Qt UI toolkit. It uses a domain specific declarative language (QML) to specify the user interface and JavaScript for interactions. There are also plans to offer Qt widgets inside the Qt Quick framework, but I'm not sure how far that project has gotten. Qt Quick is meant to deliver more dynamic / custom user interfaces.
As far as I know Qt will continue to support both approaches in the foreseeable future so which one you pick depends on your use-case.
I am an iOS / Cocoa developer looking to port one of my apps to PC platform. I don't care to code multiplatform and maintain one app. I will continue using cocoa and cocoa touch for iOS Mac Development.
I have chosen to use QT 5 for PC, I am not sure if its wise choice but its easy and I can understand c++. If its not please point me to the correct direction.
My App is not hugely complicated, but needs some special customization e.g. ListView that looks like an iOS Table View, uses custom rounded windows with twitter bootstrap style search box and I want to monitor some global OS events like keystrokes, and what other applications the user is currently working with. I also use SQLite and AES encryption.
My questions is regarding UI customization.
Should I start studying and use QML for that? I am not sure what exactly it is, seems extremely simple CSS like, but I have the feeling is more designed for embedded devices and have limitations...
Do I have access to the entire power of QT if I use QML ?
What other options I have to customise widgets instead using QML (e.g. in objective C we use subclassing and drawing whatever we want or handling events...)
I am inexperienced in windows platform. Should I use VisualStudio C++ instead of QT5? With the changes in ownership I feel somehow insecure.
Yes you should. QML is declarative language which allows javascript to be executed within it. And you can do almost anything UI related with QML. If you don't have some particular UI element you can draw it in plain C++(Qt) and use it in the QML. So QML is the best choice for Qt development at the moment. It is not like CSS though, it is much more powerful.
Yes you have all the power Qt has and additional power which declarative language may offer - simplification of UI development process as well as modern decomposition of UI&logic.
You have this option in plain C++ Qt, you may subclass widget, redraw them, change behavior etc. This approach is inferior to the QML one.
This point doesn't make sense. Some people count Visual C++ like separate language which is wrong. You may count Visual C++ as C++ + some minor extensions MS compiler has. But it is as ridiculous to refer as GCC C++. So basically you can use Visual Studio with Qt almost without a pain if you use Qt integration add-in which is freely available. Or you can choose Qt creator, which some people count as superior to MSVS. It is up to you what to choose, but I believe for the novice it is much simpler to use Qt creator with Qt. But note you will need to have some compiler because Qt creator is just an IDE it should use some 3rd party compiler(either MS or GNU one)
You can use QML Desktop Components to build easily your application:
https://web.archive.org/web/20121203050945/http://blog.qt.digia.com/blog/2012/06/06/desktop-components-for-qt-5/
http://qt-project.org/wiki/Qt_Quick_Components
Anyway I recommend you use Qt Widgets and Qt Style Sheets to costume your widgets:
http://qt-project.org/doc/qt-4.8/stylesheet-reference.html
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm going to start working on a new project. It's a 3D game using OpenGL for Windows, Linux and Mac OS X. and I'm going to need a library for GUI, windowing and handling input. I ended up with 3 choices Qt, WxWidgets and GTK+. All of them are under LGPL license.
1- Does LGPL allow to use these libraries to make proprietary applications?
2- Which one of these 3 applications is best for me?
Yes, so long as you don't statically link to them (ie: use them as DLLs). Though wxWidgets allows you to statically link without becoming GPL'd.
None of the above. If you are making a 3D game, then none of these is good for your needs. The needs of a GUI for a game are very different from the needs of a GUI for a typical desktop application. In a game, you want you particular GUI elements to be consistent with a particular artistic direction, not be consistent with the desktop environment. Plus, you may want your GUI elements to be more expressive than what these toolkits would normally allow.
It is for reasons like this that CEGUI exists. That is a GUI system designed for the needs of a game.
Also, none of these provide input the way a game generally wants to process it. You typically want something lower level for a game than what these toolkits provide. That's why projects like SDL and SFML exist.
1 - Yes, provided that your project doesn't require alteration of the library itself
2 - I strongly reccommend Qt for new windowed apps, if for no other reason than it has excellent documentation (although there are many other winning points, but it gets subjective quite quickly). GTK and WxWidgets will both make you waste mental energy thinking about things you really shouldn't have to think about. Qt is easier to a) customise, and b) ignore when you don't care about customisation.
Although for 3D stuff you might want to look into full-blown engines like, ooh, Irrlicht or Ogre3D or any of a number of others
WxWidgets uses LGPL which means you can dynamically link to it in your project, without it forcing your project to be GPL or LGPL.
However, I suggest using CEGUI instead of the libraries you suggested, for any game or rendering application
CEGUI uses the MIT license which is less strict than LGPL and also allows you to link to the library dynamically (preferred) or statically, both without forcing you to have a specific license for your own project.
Supports OpenGL 3.2+ Core Profile (OpenGL3 Renderer)
Supports very old OpenGL versions (OpenGL Renderer)
If you want to use Ogre or Irrlicht engine, which can also rely on OpenGL, CEGUI also supports these two renderers via the CEGUIOgreRenderer and CEGUIIrrlichtRenderer
Ssupports Windows, Linux and Mac OS X, just as you want
Because someone asked in the comments: Unicode characters are fully supported so that you can use Hebrew, Arabic, all sort of Asian alphabets, etc, as shown in the current Font Demo - of course you need to install either one of the CEGUI fonts or use another Open Source Font
Was specifically designed for games, simulation and rendering applications
You can skin all elements in the UI (currently only via XML, soon also using an editor)
Provides a powerful editor (CEED) for layout editing with WYSIWYG (!) for free!
Is fully extendable and adaptive via changes in C++ code and/or XML
Powerful Event System
It might take a bit to set CEGUI and its dependencies up and get it to run with your project but it will still pay off on the long run because it has a lot more features than most free solutions for UI. Imagine how annoying it would be if you used an UI library and then found out it does not provide a specific feature you need and that it would be almost impossible to add this - because CEGUI is based on C++ and XML and because of its design, you can always add specific adjustments to CEGUI. So you will most likely not run into limitations even on the long run. Also it already has a lot of features out of the box - more than comparable libraries.
After 4 years of absence I'm finally coming back to Qt development again. I'm quite impressed by the development it has gone through, but also a bit confused by Qt Quick, which got just introduced in Qt 4.7
For me it seems like something to build a quick, appealing GUI with some logic in Java Script. However, if I'm going to build a C++ application, is Qt Quick also the modern way of building a GUI for that or should I follow the classic path by using the .ui files?
Qt Quick should fill a much needed gap but whether that means it will become the way to build applications will largely be determined on the type of applications you intend to build.
Qt has provided .ui files for a long time. These files are easy to work with when you need to create applications based on standard widgets. Designer makes it easy to layout the widgets and do other basic operations.
Qt 4.2 introduce style sheets (qss) that made it possible to style existing widgets. These styles are convenient ways of styling the standard widgets to get away from the standard widgets' look-and-feel, while retaining basic functionality.
But sometimes you need to create custom widgets, widgets that don't exist. Before Qt quick, the only way to do this was to write native code (be it C++ or, with language bindings, Python or Ruby). With Qt Quick it's now quite possible to write widgets and full blown UIs that would otherwise be somewhat painful to write in code. Because Qt quick's focus is on the UI, it's becomes a better development language for that goal. The Qt Quick paradigm also transcends the idea of strict standard widgets, adding support for transitions and boundary-less widgets.
The answer really depends on the type of application you're planning to build and I consider the description provided on the page you linked to very accurate:
"Qt Quick helps programmers and designers collaborate to build the fluid user interfaces that are becoming common in portable consumer devices, such as mobile phones, media players, set-top boxes and netbooks."
At the moment, Qt Quick is certainly not the most obvious choice if you're planning on building a classical desktop application, an area of development which the Qt library traditionally excels at, and in this case you're probably better off using what you call "the classic .ui approach"; at the same time, I think that's the exact reason why Qt Quick was introduced: to add a new tool to facilitate the development (or rapid prototyping) of applications not focused on the desktop.