Qt has traditionally strived to provide a native look and feel on all its target platforms and does not really have a strong visual identity of its own. This will not change in Qt5. However Qt also used to ship with a whole range of extra styles as well. With the modular nature of Qt5, it is clear that including over six different and mostly outdated non-native look and feels in every single deployment of Qt is a rather silly thing to do. After all, how many times have you had the need to see how your application would potentially have looked on an early 90's solaris workstation? It is about time that we clean some extra baggage from the base install of Qt.
The styles we are primarily planning on removing are Motif, CDE, Cleanlooks and Plastique. If Windows (classic) is still going to be provided as a cross platform style is still up for discussion as there are still some dependencies that would need to be sorted out first.
We are also planning to remove the remaining style headers from the API itself to make it possible to replace or remove deprecated platform styles in the future. QStyleFactory and QProxyStyle will of course still allow you to create and modify them without hard dependencies.
Before anyone panicks, keep in mind that we are simply removing them from the base install of Qt5 so that every single deployment of Qt will not have carry the extra baggage. Applications or developers that need or use them for specific purposes will still be able to get them as plugins from a new qtstyleplugins project repository
The old Motif and Plastique styles - No longer included
We know that there were a few reasons why certain applications would chose to use these styles instead of the native theme. They could sometimes provide better support for custom colors and they make it possible to have the same look and feel across multiple platforms. On the other hand they were all starting to look rather dated and would have needed a complete rewrite if they were going to support new features like scalable UIs or retina displays.
Given those use cases, I thought it would still make sense to have a simple non-native look and feel with Qt that could handle all these use cases but look a bit more fresh and up-to-date. We aimed for a clean look that puts focus on the content, rather than trying to stand out on it's own so that it could be used in a wide range of contexts. The result is Fusion style as shown in a few different color configurations here.:
Fusion Style - New in Qt5
Commenting for this post has ended.
Fusion looks great on Ubuntu. What does it look like on Windows and OSX?
danny77uk: It is platform independent so you would expect it to look pretty much the same apart from default system colours which can of course be customised if it is required.
You can check out a screenshot from Windows 7 here: http://i.imgur.com/0JI7X.png
Here is a screenshot on Mac: http://i.imgur.com/U8wqN.png
(edit: added screenshots)
Thanks for the additional screen shots. The tabs look a bit odd on Mac as OSX hasn't had 'tabs' since Jaguar (OSX 10.2).
Check out this video:
http://www.youtube.com/watc...
It shows a standard Windows GUI application made in Delphi, with normal widgets and all, being converted to the Metro UI. Metro really kicks ass, it would be nice to have a style for it in Qt.
Daniel TM: A bit off topic perhaps. The video shows some widgets with a metro-like color scheme and doesn't really reflect the ideas or concepts behind metro. A basic style is unfortunately not going to be enough to transform a desktop app into a tablet optimized metro app. Windows 8 already provide a new and cleaner look and feel for widgets that blend better with metro. This is what Qt will use by default. This delphi app would actually look more out of place since it doesn't actually run inside the metro shell but alongside your other Windows 8 desktop applications. To provide a full-blown metro experience, I think we will have to make qt quick run inside the Windows RT runtime itself and possibly introduce some simple QML components for it.
You probably mean WinRT, not Windows RT (these two terms mean two different things).
Indeed I do. I find the whole Windows 8 branding story a bit confusing :)
So there no longer will be separate platform specific UIs or am I reading it wrong
You're totally off. How the fuck could you come to that conclusion?
No, the old cross-platform-styles (i.e. non-native ones) were abolished and replaced with a new, custom one.
Of-fucking-course the native styles will continue to exist.
MySchizoBuddy:
You are reading it wrong. :) Windows will have windows styles, Mac will have the mac style and we will provide gtk style on linux. So nothing changes there. This is just about removing some older styles that were not platform specific and mostly useless.
This sounds like a nice step forward. I never used the other styles when shipping for Windows and Mac and disliked the extra bulk required for deployment. Important question: does this mean while compiling a patched version of Qt on Mac I won't have to wait watching the other styles compiled either? I presently use "-no-gtkstyle" but that only disables one of the styles.
I was going to complain about Plastique removal, but Fusion looks good, so it doesn't really matter now.
Ditto. There are Linux installs without GNOME or KDE, so you still need default X11 look. For a while reading the article I was worried it would have to be Windows style. Thankfully Fusion looks like a good successor to Plastique.
Will Stokes: Yes, exactly. On mac the only styles you will get after running configure are Mac and Fusion (and possibly Windows). I dont think you really need to pass no-gtkstyle unless you are actually compiling on linux as it is simply not included by default on mac.
Fusion style looks like a worthy successor for both Plastique and Cleanlooks. I would not remove Windows style, though, because it is the only remaining style that does not use gradients or extensive pixmap caching (which might be expensive for some remote systems).
Cristoph: Well that is still not really an argument for keeping Windows style in the mac and linux binaries. After all such systems would anyway not be using the precompiled Qt distributions. We still have to keep it in the repository as the Windows platform(s) are using it so other platforms should be able to simply pass -style windows if they really need it. The idea is just to remove the dependency.
What about the GTK style? Is it going to be ported to GTK3?
Matthew: Certainly but it is probably a bit too late for the 5.0 release given how busy we are at the moment. We already cleaned up some legacy code in the gtk2 style to facilitate this and we have some experimental patches that allow it to run against Gtk3 already, but it will need a bit more polish before we can fully support it. Perhaps an experimental addon after 5.0 would be a good idea.
Cimi likes Fusion :-)
Well done mate!
Don't forget to update the gallery page when you're done:
http://qt-project.org/doc/q...
;-)
Andrea: Thanks :)
David: Indeed we should. There are plenty of style changes left though.
Thank you - its long overdue. You can also remove windows style.
>> .. remove the windows style
or, at least update it to windows 7 look
vasu, there are actually three distinct Windows styles in Qt: Windows "classic", Windows XP, and Windows Vista (also used on Win7).
"Windows" does not need to be updated because a Windows Vista/7 style already exists alongside it. Here is a comparison of the three Windows styles:
https://qt-project.org/doc/...
https://qt-project.org/doc/...
https://qt-project.org/doc/...
Very nice the new Fusion style!
Reading your article:
"...to support new features like scalable UIs or..."
"Scalable UIs" sounds very interesting.
I've wrote a simple application with desktop in mind but now i'm interested in porting
it to mobile devices (and display...). I've wrote all in C++ widget based, not using xml,
and i would like to continue this way.
I've read here:
http://doc.qt.digia.com/qtc...
and i'm searching for some docs redarding the third point:
"Design for multiple screen sizes"
Relate the position and size of each control to the dimensions of the display. This enables the same set of information to be presented on the screen in all resolutions; higher resolution devices just display finer graphics.
What i would like is to be able to scale the entire child widgets starting from mainWindows
but I don't know how to do that nor if it is possible (I would like to do that from C++).
Can you, or someone else, give me some suggestions or point me to some good and
updated doc regarding this topic?
We are not adding any other scalability options to UI's aside from what is already possible with GraphicsView and retina displays. I am afraid QML is far better suited for such use case as it was designed primarily for it. But if you want to try to do scaling of widgets, you can place your widgets on a graphicsview and set a scale on the entire scene. Keep in mind that this would be a global scale and quite easily make text unreadable and buttons too small for touch.
http://doc.qt.digia.com/qt/...
Obviously I do not expect to obtain a good result with a simple scale of the actual interface. Anyway, a previous customization conditioned to the size of the screen and a scale capability i think can be enough.
I will check for graphicsview, thank you!
F
A bit OT but can we ship Qt5 already? It was promised in May 2012 and you guys are busy cleaning up irrelevant stuff. If this is so important, well break BC in Qt 5.1 or whatever. But ship the library already and focus on getting a functional mobile story. Qt is already irrelevant (unfortunately). Extremely poor/non-existent project/product management.
Used by Autodesk Maya, The Foundry's Nuke, Adobe Photoshop Elements, Skype, VLC media player, VirtualBox, and Mathematica, and by the European Space Agency, DreamWorks, Google, HP, KDE, Lucasfilm, Panasonic, Philips, Samsung, Siemens, Volvo, Walt Disney Animation Studios and Research In Motion.
Yes, Qt is "already irrelevant".
None of those use QML, which has become the primary focus of Qt. Qt is no longer developing on the features that make it good, sadly this spells out a bad perspective - those companies will continue using Qt as long as QtGui is supported and then will abandon the framework, because it doesn't pay any attention to the needs of serious development scenarios - QML is for toy apps.
> "None of those use QML, which has become the primary focus of Qt. "
This is simply wrong. For one, Research In Motion is only interested in the QML aspect. Others are too but not necessarily on the desktop. They are using it for in-flight navigation, car sat-nav and a wide range of other use cases.
> Qt is no longer developing on the features that make it good, sadly this spells out a bad perspective – those companies will continue using Qt as long as QtGui is supported and then will abandon the framework, because it doesn't pay any attention to the needs of serious development scenarios – QML is for toy apps.
Strongly disagree here. If you havent noticed, this post was primarily about changes done to improve QWidgets. We are among other things adding retina support and massively improving accessibility on all our desktop platforms. We are also working on adding features like native Gtk3 styling.
Those are new features designed to make widgets stay alive and relevant for what they are designed for. What you are referring to as "toy apps" is what others would refer to as "touch", "phone" and "tablet" apps. In todays marketplace, providing a good looking touch UI is getting increasingly important. Treating these as "toy platforms" is a sure way to make your technology irrelevant in the near future. We will not and cannot make QWidget work remotely as well for these use cases because it was not designed for them. QWidget and QtQuick will both be relevant and useful in the future. We will soon also enable Qt Quick to work a lot better in the desktop area, but that belongs to a different blog post.
1 out of 20 using QML doesn't make my claim "simply wrong" it makes it 95% right. And no, by "toy apps" I don't mean touch apps, I mean your typical 5$ app that is nothing more than an interface to some web service that has no suitable frontend for a small portable device, applications that are almost entirely eye candy with very limited functionality, the kind of apps there are already dozens for every particular user case.
The problem is not in the focus on a touch GUI API, the problem is the exclusive focus on QML and the lack of a public native API. No matter how much you try to pimp QML and claim it is the best thing since sliced bread, the fact of the matter is an overwhelming amount of Qt developers don't like it, QML offers nothing new, it is long overdue, a pathetic attempt to follow a moronic trend most other companies are already walking away from, the flaw is not in QML markup itself, the problem is the attempt to make it a proprietary language that gets all the new features of Qt exclusively.
QML will be the decline of Qt in the long run, and by the time your management realizes this you'd have wasted years of precious development time that could have been invested into much more innovative and efficient directions. QML makes certain aspects of development easy, but in the case of more complex, professional software using QML becomes a tedious burden, a nonsense you have to conform to for the sake of getting new funcitonality. Between the bother of implementing modern GUI with QWidget and doing everything QML does out of the box by hand and conforming to QML just for the sake of all the new carefully designed to be exclusive to it new features I'd rather abandon Qt and embrace other alternatives.
As usual, feel free to ignore the concerns and requests of your developer base and insist what you are doing is great simply because you obviously fail to envision anything better.
I am sorry you feel this way.
You might have noticed that the mobile strategy we had planned to deliver in May is no longer relevant and releasing a product that was highly tuned for only one platform makes a lot less sense now. The project goals were essentially reset and we lost a lot of manpower on top of that. What you are seeing is that we are repositioning Qt5 to be relevant on a lot more platforms including the desktop and I think it is worth taking a little more time to do that properly.
Excellent point and extremely great to see that focus is shifting away from a single mobile platform (which was very disconcerting) and back to the desktop and various mobile platforms!
Agreed, refocusing on the desktop is much appreciated. Qt is quite relevant, and it's telling that all the examples listed of it's usage are all on the Desktop. Of course the iOS and Android ports coming down the pipe will be interesting, much more interesting then the Symbian related efforts in the past.
I want to see console style gui, like ncurses for QCoreApplication. =)
like this? http://blog.forwardbias.in/...
No, like Turbo Vision =)
http://tvision.sourceforge....
I am a huge Windows Classic user. I know I'm not in the majority, but when stuck on windows it is acceptable. I rather like the newer linux ones though.
We are certainly not planning on removing WindowsStyle on Windows itself so you have little to worry about. (apart from the fact that Microsoft have deprecated it on Windows 8) I simply dont think it makes sense to also ship it on Mac and Linux binaries. Another significant change we are planning for Windows is to merge WindowsXP and WindowsVista into a single UXTheme style, but that is mostly an implementation detail as the end result should work the same.
I always tought that some fresh air in the style compartment would have been a good idea. To be honest I've only used the native looking styles until now, but having some usable option is a good thing.
Anyway, maybe a bit off-topic: has someone tryed how are QWidget applications lloking with macbook retina displays?
I agree that the new fusion style is a great replacement for the Plastique style that I've used in my app !
Speaking of Qt 5, when can we expect a beta SDK (Qt Creator+libs) ?
Also, will there be any update to the 4.8.x SDK ?
Qt/Cocoa 4.8.3 does fairly well on a retina display if you update your Info.plist. Specifically text and custom painting with paintEvent works automatically. Icons and images, and button icons are another matter and are being worked on.
Hi all,
Just a heads up for people interested in the "legacy styles" (Cleanlooks, Plastique, Motif & CDE) that were recently removed from qtbase. As promised, the aforementioned styles have been made available in the newly introduced qtstyleplugins repo: https://codereview.qt-proje....
Here's a preview of high-dpi retina reasonable resolution Qt styles:
Mac: http://i.imgur.com/BOfHK.png
Fusion: http://i.imgur.com/mItAY.png
I cant believe you posted a screenshot of Fusion in retina without giving me a chance to fix the bugs first.
Just pointing out that we are fully aware of the issues but Morten is the only guy with a retina mac in the office right now. ;)
Sorry Jens! Updated screenshot here: http://i.imgur.com/TzZKD.png
Wow well done on the retina stuff guys! Looks great!
Hi Qt devs,
What about OpenGL and retina display ? Would you address this in Qt 5 ?
Hi,
How can I se these three different colors under QFusionStyle?
They are essentially just tweaked using Designers palette editor. Just open a form in designer and click on the palette section. Alternatively you can try the built-in palette by doing qApp->setPalette(style()->standardPalette()).
I really like the third dark fusion palette. Now, I'm badly color blind and can't mix my own palette to save my life. Could you post the palette used for the dark fusion snapshot?
I dont have the original but you should be able to get close by just setting these colors I found using the colorpicker tool:
window/button: #353535
highlight: #8e2dc5
The main trick to making your own color schemes is to use gray or only very low saturation on the background color. For the highlight color you can be a bit more bold but avoid strong primary colors like full red or yellow. Follow those rules and almost all the schemes look reasonably well.
Thank you very much, it looks great now!
One advantage of these "old" styles is they are the only styles (besides native styles) reponse correctly to the system color changes (at least under windows).
They are also prefered by lots user.
It would be helpful, if these styles would be still supported.
Actually there is no need to support them for this. We made sure that QFusionStyle works better with palettes than any of the existing styles. Windows classic style is still available everywhere and you still get the color changes from the system, even when using Fusion.
If you for any reason still need them, the removed styles have been made available as qt addons so you can download and include them with your application.
Not quite sure, but one thing is that in Qt5 I have to restart the application to make the system color changing take effect for all the styles, which is not necessary in Qt4.
[Apologies for bringing this post up].
I've built Qt 5 on Ubuntu, and I wonder how to enable Fusion style. By default Qt 5 applications use Win2K-like style. QtConfig allows me to select Fusion style (and get a preview of it), but it doesn't get applied actually. I've figured out that QtConfig adds "style=Fusion" line to ~/.config/QtProject.conf. Is that the right file?
P.S. Starting apps with "/path/to/app -style fusion" works.
How did you manage to find qtconfig for qt5? I've been googling for hours with no luck. I'm struggling to get qt5 to load system icons. Works fine on qt4
@Pieter:
How did you manage to find qtconfig for qt5?
I've built it myself, after fixing a few warnings: https://codereview.qt-proje....
I'm struggling to get qt5 to load system icons.
Here's my proposed patch to get those working: https://codereview.qt-proje....
I have never, ever, liked the default looks on KDE (and believe me, I've tried many times over the years) but this new Fusion look is absolutely gorgeous! Fantastic job.
I'm also so pleased that they finally got rid of that irritating x in the check box and replaced it with a tick. It always bugged me to see a negative symbol (used for Close / Exit, No, Delete etc) used for a positive selection action.
I would love to see a screenshot of that actually. Did you use the qt4 backported version or did you compile KDE with qt5?