Qt Design Studio 1.0
blog.qt.io
blog.qt.io
My startup abandoned .NET in favor of Qt to develop a cross platform screenshot app to digitize math equations because we wanted Linux support (https://mathpix.com) and it's delivered. We still use Swift for our Mac app. The thing about .NET is that it's not nearly as seamless as a development stack as Swift + the whole Mac ecosystem. Whatever clunkiness exists in Qt apps already exists 10x in the Windows ecosystem of clunkiness everywhere, because Windows itself is, in a sense, cross platform. So the difference between a Qt app a .NET app is not super noticeable on Windows.
A good Qt app will be very nearly as good as a good .NET app, and a good Swift app on MacOS beats them all by a landslide.
In what sense(s) does the final application end up better?
Qt is really good for quick bringup of a cross platform app, and Designer and its associated code generator does a good job of generating reasonable UI's. Swift didn't exist at the time, but the combination of InterfaceBuilder and Cocoa was amazing.
Where things start to get tricky is that Qt has to reimplement a lot of widgets themselves, on account of their target platforms being quite different from each other, so you end up with a slightly non-native feel on each platform, and some behaviors are subtly different. Things have gotten better since then, but that non-native behavior is still there. These behavioral differences aren't too bad on Windows and X11, since those platforms have a lot of inconsistency between apps, but mac users expect the mac to "feel" a certain way, and Qt is a little different, so we got a _lot_ of feedback, some of which I still remember - "Google Earth looks like it fell out of the ugly tree and hit every branch on the way down".
The tradeoff you have with a cross platform toolkit like Qt is quick bringup of a cross platform app, versus later chasing down a lot of platform differences causing problems, and that slight non-nativeness. The alternative is to write your UI natively on each platform and abstract away the functional core from the UI, which is a lot more work but works better. If I was building a UI for major public consumption today, I would go with the extra work of native UI. If I was building tooling for my own developers, hands down, I'd use Qt.
QT = UI library.
What did you write your back-end code with? C++ ?
(You mentioned that the Mac version is written in Swift, but what about the Windows and Linux versions)?
You can use it as a simple gui library just fine. I've been using it in place of Tk for my python stuff for a while now. (Qt.py is a lifesaver) I haven't even tried their options for what I want to do yet, but it is definitely tempting.
Here's a good list of things Qt has stuff for.
Oh no! Why then Qt is all over my server code?!
Where do you fit Qt's support for networking, SQL databases, standard directory structures, multithreading, etc... ?
Swift is developed by Apple for Apple ecosystem. Thus, the native calls are of course efficient.
Qt is a framework that works as bridge between the native calls and your application, the same applies for .NET.
If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls.
Why don't you use Qt on Mac then? The main advantage of using such a framework is that you have only one codebase/language that runs everywhere.
> If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls.
Not so. Both frameworks make calls down into one of Windows' graphics subsystems. This is how all GUI toolkits work.
If draw performance is important to you, Qt might well beat WPF, as it has a Direct3D 12 backend [0]. To my knowledge, WPF does not - as far as I can tell it uses Direct3D 9. Of course, none of this gives us any hard assurances that the performance of one beats the other, but in terms of the inefficiencies of using intermediate layers, it's far from clear than WPF wins.
(I couldn't find any decent concrete numbers on this. I presume that's because GUI draw performance isn't a real problem these days.)
I'm not convinced that Swift is any different (though it well might be a good deal less bloated). It seems unlikely that the syscalls end up all that different simply because of using a different language for your GUI work.
> Why don't you use Qt on Mac then?
Obviously I can't speak for nicodjimenez, but I presume it's because Qt doesn't deliver quite the native Mac feel that they're aiming for. My understanding is that Qt is also a little immature on mobile platforms, but I'm not sure that's relevant here.
[0] https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d...
.NET Core 3.0 will apparently finally bring .NET Native to Windows desktop apps as well.
WPF is somewhere else; as the sibling commenter told you, it is a .Net framework, so it has entire .Net VM underneath.
Not exactly and this view of it is IMO why a lot of people dislike it: MFC is not a layer like Qt, you don't use it to avoid Win32, you use it to enhance Win32. When using MFC you need to know both MFC and Win32 and you use both of them at the same time. On the other hand when you use Qt you can ignore anything related to Win32 because the Qt API layers itself over whatever is below.
Of course this has several implications, starting with that if you don't like Win32 then you wont like MFC either (and the reverse isn't necessarily true - you may dislike MFC while liking Win32).
Qt (Quick) is on the same level than WPF actually. Both create a scene graph and render it. WPF does not use native windows primitives.
A product that I've been keeping an eye on is Subform [1]. Apart from Flash-esque design tools, it includes more or less "novel" ways of defining the layout of the app. I think the layout tools set this product apart form similar offers. One of the main developers has a talk about the philosophy behind the UI of this app [2].
The same team is working on an app to use state machines to define UI interactions, which is also super interesting [3].
2: https://www.deconstructconf.com/2017/kevin-lynagh-choosing-f...
Dude, hate to be the bearer of bad news, but subform shut down, during beta.
I also was keeping track of it and hoping it would launch.
sketch.systems is created by the same people though, and sketch.systems is pretty much their pivot. not quite the same thing but it seems to be receiving a better response in the market.
I just saw that they haven't updated the blog since March or so, but I wasn't sure since their forum is invite only. Did they announce this somewhere? Perhaps they are taking a break from subform to work on sketch.systems.
They announced it on their invite only forum.
> Perhaps they are taking a break from subform to work on sketch.systems.
That’s exactly what they’re doing, except for it being a break.
Flash survived longer than most just by developing into a Web-centric product, but for the most part, these products are old and there's room for a new generation of them. The thing that I think has held them back is that it requires a more holistic approach than is usually taken by open-source projects. It's easier to make a programming language that is dumped on top of the C/Unix environment and just accumulates power-user features over time.
I think the key lesson, really, is that you need intuitive metaphors to make such things work. The idea of cards and stacks are highly intuitive in this case.
It's worth booting up Sheepshaver and giving the final version of Hypercard another look. The default home stack -- complete with interactive examples and documentation that you can straight up copy and paste -- is still a marvel of design in my view.
That the results aren't as good isn't surprising. Flash was specifically built (and optimized) for interactive graphic content like games. HTML was originally made to display text documents and it's been a long series of revisions and hacks to get where it is now.
It wasn't just games. Every damn website had a flash animation that autoplayed and got right in your face.
Flash was also used to bypass privacy controls, create un-deletable tracking cookies, and generally do bad things.
Remember when we needed to update Flash every couple of weeks because it was so full of security holes? And they were serious holes, used by bad people to do bad things to a lot of innocent victims. And, of course, while we were downloading and updating the Flash player, the web was basically useless because every damn site refused to do anything until it could do it with Flash.
No, much as I loved those games, I'm soooo glad we didn't go down that road
Flash, while full of issues, was sort of a prototype of functionality that people wanted built into browsers. It took a while for standards to catch up, because standards move slow.
At the same time, people were motivated to make it happen because of all of those terrible things about Flash.
We can all thank Steve Jobs for delivering the death blow to Flash to really force the issue.
This is kind of funny to see for me after spending a lot of time years ago trying to make some performance intensive games and stumbling on the horrible performance (and API limitations) that Flash - at the time i wished i was able to make applets instead :-P.
I'd argue that's a very good thing. Obviously lots of people disliked the Flash player for various reasons, but the Flash authoring tool was terrific. Specifically, the features/metaphors it comprised are IMHO precisely the recipe for a powerful design tool:
* Composable hierarchy of objects that can contain other objects
* Each object has states (keyframes) and state transitions
* Each object is an instance of a class, and editing the class affects all instances
* Code can be attached to each object / state / state transition
The only contender to Qt in these companies is usually WPF.
Microsoft OneDrive is made with Qt, the Blizzard launcher, the AMD drivers panel, authoring software like Guitar Pro, Maya, CryEngine, Allegorithmic software (one of the slickiest UIs in that field I think : https://www.allegorithmic.com/)... Blackberry also used Qt for their OS's shell and apps, as well as HP/LG WebOS.
Qt Quick was introduced in Qt 4.7.
+ Rightware Kanzi (https://www.rightware.com/kanzi)
+ DiSTI GL Studio (https://www.disti.com/user-interface/gl-studio/)
+ Altia (https://www.altia.com/)
Most of them have found niche markets in verticals like automotive/medical/embedded, where it's easier to just ship a runtime for the UI.
UI/UX designers working on the dominant platforms (web/mobile) have a lot of nostalgia for Flash--particularly the perceived ability to actually ship functioning product. There's no lack of new tools trying to improve on the status quo: drawing pictures of UI and throwing them over the wall for developers to figure out how to implement.
I suspect that we haven't seen the aforementioned IDEs become industry standard for a couple reasons:
+ They're by nature more difficult to use than drawing tools, often surfacing a lot of advanced parameters, state machines, and code
+ The variability in languages/frameworks/platforms inherent in web and native development make usable output a much harder problem than having everyone all-in on a single framework/runtime
I know QT is this big powerful thing, but where does this fit in compared to QtQuick/QML/QtCreator and so on? My frame of reference is .NET desktop development FWIW, but this looks like some cross between VS Blend and Adobe Flash/Animate.
I'm pretty sure that is incorrect, can someone please enlighten me?
So this looks like a design tool for creating QML interfaces. The animation parts come in because QML allows for embedding javascript so you can probably do all of that graphically now and get QML code out
Hooking QML into actually doing something useful? That's a whole different can of worms.
Still, each time I think of using QT I get discouraged (a bit) by the licensing (even though there's almost zero chance I'll ever independently sell a software product! :-p).
In paper, one should be able to use the community version of QT for commercial software, but it looks like actually doing this could be really tricky [1]. And the commercial license is so expensive! QT page says: "Pricing starts at $459/mo." :-O.
1: https://www.quora.com/Can-I-use-the-free-QT-for-c++-commerci...
Unless you start to mess with the QT libraries directly, there should be no problems whatsoever. You just attach unmodified object files and/or source code (as you did not make changes to them) into the software distribution.
But there is a "problem" using Qt to release proprietary software, of course, because Qt is free, and perhaps parent isn't aware of the distinction between commercial and proprietary?
(That said, whenever possible please give back to the FSF community)
This is of course complicated by SaaS and all that is covered in more detail in Affero license and in that field I'm out of my depth.
Oh also, I am not a lawyer, if you're developing something commercially or otherwise reading this for advice please take a moment to consult a professional.
> Oh also, I am not a lawyer, if you're developing something commercially or otherwise reading this for advice please take a moment to consult a professional.
Absolutely!
> Qt Design Studio is available today as a free tool for everyone to try out and evaluate. You will need a commercial Qt developer license to distribute your UIs created with Qt Design Studio.
> We are also working on an open source version with a limited feature set, to be published in December.
The Qt library itself has both commercial and LGPL licenses. You can safely use LGPL libraries in commercial products with a couple obscure provisions: it's commonly held the library has to be dynamically linked, the user has the right to replace the Qt dynamic libraries, and maybe a few other inconsequential things.
I know one major vehicle manufacturer that won't go past 5.6 because of this reason. They put it right in the RFP.
I'd think a major vehicle manufacturer should be able to pay for the commercial license?
For them FOSS is a way to cut down development costs, while not contributing anything back, not even bug reports.
The legal and warranty issues around letting customers reflash their dashboards are what the company wants to avoid.
Therefore, they are deliberately chosing to use the FOSS version to avoid to pay the commercial one while keeping their hardware as closed as can be.
"Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source."
So not exactly the toolchain, but definitely allows reinstallation of upgraded libraries. I didn't know.
Working in (or for a company from) a very expensive/rich technological hub of the world, i.e. couple of places in US, couple in Europe and couple in Asia.
At least in Europe "decent" would mean "top 1%" - because it translates to ~300k€+ before taxes.
Way above "decent" engineer salary for the rest of the world, but I guess that's plausible in US?
So I was estimating roughly a $150k engineer. That's high in some places and low in others. But at least in the U.S. in any significant metro area, that's not an unreasonable marker for a senior engineer.
However, it hardly seems meaningful to squabble over where $150k sits in the range of software engineer pay scales when we're comparing it to a $495/mo potentially productivity boosting alternative. $6k is a lot less than $50k, $100k, or $150k.
To them, the world has moved on. Web apps have zero consistency and people prefer them. There is also little money left in desktop application development. Qt on Android and iOS targets the "good enough" rather than driving their business. The people who will choose Qt for mobile don't do it for consistency. The money is on IoT and embedded. This is where having a certified platform with support is important. It's also where you can't use the OpenSource license and have to pay for the commercial one. It's also where having native UX is absolutely irrelevant.
In a way, it's hard to argue about any of that. It's sad, but unavoidable.
To render text nicely you need to know the geometry of the screen so you can anti-alias properly. A canvas goes through a series of transforms that work fine for images but garble text.
It'd be nice to have a web layout tool that ties it all together and lets the designer use familiar tools like pivot, anchor, align, etc. - even if it exports some proprietary combo like react + styled components.
No doubt that's what FramerX and friends are after... so I guess there's progress, but it feels like the web just needs an overall rewrite to get out of the legacy cruft that came along with making static pages dynamic.
Oh wait...
The library has two core strengths: it works on virtually every platform that can run a GUI and the application code can be made to be pretty much agnostic of the underlying OS. Unless an application uses OS interfaces directly for fancy things, most of the porting work is just recompiling the code.
I think the reason for this is that Qt has extremely high quality widgets and graphical elements. They allow you to do things out of the box that would be crazy hacks with most of the competitors. And the options for styling the UIs are very good, too, which matters a lot for these embedded use cases.
Is Qt hard to get into? Yes and no. In C++, you are required to use some mechanisms like signals/slots, which are used for routing events. These features look like non-standard language extensions and rely on a special source code preprocessor to generate the glue code that is implied. The other concepts are easier to pick up. And the toolkit is very consistent in the structure of its interfaces, so once you pick up the patterns, you can get very productive.
If you’d like to make graphical applications though, I recommend immediate mode frameworks
Is there a way to use this without Boost?
QML is closer to a game engine than a widget toolkit. It is intended to provide an easy way to animate everything and create custom looks. It feel alien for a few months before you "get it". It is very powerful and easy to use, but the learning curve is steep and when you hit the limitations of the framework, have fun making any progress beyond it. It's also a bit hostile to native and modern code. Shared pointers are ignored and crashy. The binding between C++ and QML is also not the fastest thing in the universe.
I am writing complex apps using both as my bread and butter. I would not recommend QML for quick prototyping of complex apps. QtDesigner/QtWidgets still beat it. However if you need touch or fluid and modern looking GUI, QtWidget is a dead end and QML/QtStudio shine. It's really a project per project choice. They fill different niches.
> Isn't it convenient to develop the whole app GUI in QML/QtStudio and use HTTPS to communicate to a backend without using any kind of pointers
It /can/ be done, but almost nobody uses Qt that way. The web stack is a better fit for this. Pointers are not scary. Alsmost all languages these days use pointer (object reference) by default and it scares no one. Qt doesn't mix pointers with scoped/std::move in the default API, so you wont shoot yourself in the foot by accident. QObject, the base C++ class of every Qt component is reflected into the QML vm automatically, so you can use your objects on both side without any overhead or synchonization. You just need to add the `Q_PROPERTY` and `Q_INVOKABLE` macro in your header and QML will see it.
> Isn't it convenient to develop the whole app GUI in QtStudio
I honestly still think that's impossible. QtStudio isn't (yet?) close be being a good IDE. It aims at closing the gap between designers and coders. For pure coders, writing QML by hand is more predictable.