Web Based Qt Design Viewer
qt.io
qt.io
At the time, I was told that this was basically just a tech demo, and accessibility was actually the browsers' fault because there wasn't a Javascript API, and that all of the touch controls were going to be fine, and implementing all of the browsers' input methods by themselves was actually better than messing with CSS, and everything would be fine if I was patient.
So now, checking in, I can see that scrolling still doesn't work on my Mac, that the demos still aren't responsive and completely ignore the window width, that I still don't have any accessibility options, that keyboard shortcuts like `tab` still don't work, that text still isn't selectable or searchable, and that right-click is still broken.
For the cluster example[0] I'm downloading 30 MB! of code to render just three gauge charts on a page that uses 14MB of RAM. CPU fans immediately spin up -- I'm plugged in, but I can only imagine what this demo would do to my battery life.
I'm very excited about WASM, and there are some communities doing some really exciting things you should check out. Rust is well on its way to being a first-class language on the web. .NET had some really interesting demos. .NET actually renders your components as HTML, so there's potential you could use C#/.NET for practical web development, and not just for a quick port of an existing app. There are people doing cool things here.
But I don't think Qt is built for the web. The devs are trying to cram a square peg into a round hole, and I'm skeptical that their future efforts will be any better. My understanding is that even on native platforms, Qt does a lot of behind-the-scenes rendering computations that then gets painted out as a pixel array. If that's true, that could explain their insistence on doing the same thing here, but... that doesn't make it any better.
Don't use a WASM compiler that spits its entire interface into a canvas as a pixel array. I've seen a few people call this Flash 2.0, and honestly I think that's doing a disservice to Flash. Flash had better accessibility controls than this.
[0]: http://qt-webassembly.io/designviewer/#ClusterTutorial.qmlrc
In the current state, I don't think it would be accurate to say that Qt supports the browser platform, and given the fundamentals of their approach (webGL), they're unlikely to get to an acceptable level of support any time soon.
Someone else brought up legacy codebases, which I can see a use-case for. I could also see a use-case for letting people do design reviews on your native app without forcing them to install a new build.
But would anyone here feel comfortable shipping this kind of output as a commercial product and advertising that your app had web support? I wouldn't.
- Cash registries
- Hotel booking
- Factory management
Etc.
I agree with others in that using wasm to build a web app would be lunacy.
Figma:
1. https://www.figma.com/blog/building-a-professional-design-to...
2. https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
wasm is great. I just don't think Qt's wasm port is in a state where companies can just compile their desktop application, throw the resulting module on a web server, and then expect a decent result.
Ignoring the fact that most desktop applications aren't designed to be ran on a mobile-sized screen, Qt's accessibility support is non-existent (at least that was the case when I last evaluated their tech preview).
So to rephrase: Naively porting desktop applications and presenting them to customers as a first-class product would be lunacy.
> Pulling this off was really hard; we’ve basically ended up building a browser inside a browser.
So I played around a bit with Figma. It is notably better than Qt, because the only thing it's using WebGL for is its main canvas. When I saw that comment in the linked article, I assumed Figma would be making most of the same mistakes as Qt.
But all of the menus and site controls are normal HTML, and that helps a lot (although, holy crap learn how to use elements other than divs/spans).
It's not crazy to me that you would have a section of your app that fell back on custom conventions, that's what Canvas was built for. Apps like this explicitly are the use-case. However, there are still tradeoffs from that, and Figma's main canvas suffers from most of the same problems as Qt. The scroll hijacking feels really weird, it's totally inaccessible to screen readers as far as I can tell.
And it's not entirely clear to me why it was built that way. What makes it weird is that as far as I can tell, Figma projects export to HTML/CSS. I don't understand the line of thought that makes a programmer decide to completely reimplement something the browser gives them for free. It's not like they need to support older browsers, they're relying on modern WebGL and WASM. Why wouldn't they want a true WYSIWYG editor?
Having those 30 MiB of Qt library precached in the browser may be the solution to the load times.
HTML/CSS was designed for documents.
QML was designed for application GUI.
Qt is not built for the web because web is not built for the GUI apps.
This position that we have to abandon the browser because XML can't handle application state gets brought up a lot and sometimes it's true, but most of the time it's not. I can count on almost one hand the number of native applications I have on my computer that couldn't be reasonably trivially represented in HTML.
And even the majority of those apps only have specific sections that would need to fall back to WebGL. Inkscape springs to mind, just because I currently have it open in front of me. There's almost nothing other than the main canvas itself that would require a custom renderer if you wanted to port Inkscape to the web.
Remember that HTML is not a layout tool, it's a render target. The point of HTML is just to represent state to users in an XML-based format.
Regarding the issues you see: They ignore the browser width (and your other "issues") because they were designed that way. Check out: https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/qtb...
from https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/ind...
Seems responsive to me, tab works fine and dandy, text is selectable, right click works fine as well. I dunno what you are complaining about.
Other Qt WebAssembly apps behave like you want them to.
Rust has had this figured out for a while. You build a few helper methods in Javascript and call them from WASM.[0]
WASM has access to Javascript, so it has access to everything in the browser; that's already how Qt is getting the mouse position and intercepting keyboard events. Spitting pixels onto a canvas is an architecture decision, not a language restriction -- it's possible to build accessible WASM apps.
> Seems responsive to me, tab works fine and dandy, text is selectable, right click works fine as well. I dunno what you are complaining about.
From a quick test in Chromium:
- Right click won't work on mobile (long presses should trigger a right-click).
- Clicking on the main document to enter edit mode is broken via touch controls. You literally can't enter edit mode at all.
- Tab support is poorly implemented. On the web, when we talk about tab support, what we mean is that you should be able to use the entire interface from the keyboard. Here if you open a menu you'll immediately get stuck in an infinite loop. This is something you'd get for free if the menu was rendered with a <ul> element.
- Scrolling is inverted from my browser settings.
- Middle-click scrolling doesn't work at all.
- Searching for text doesn't work at all.
- On mobile interfaces or when looking at the app in responsive design mode, the entire interface gets scaled by a fixed percentage. This is particularly interesting, because that had to be a conscious choice. Container sizing just works on the web, I would need to think about how to break something like that.
- I don't know if the intention was to support all of the keyboard shortcuts the app lists (ctrl-f/command-f), but a lot of them don't work. I'm impressed that command-z gets correctly interpreted as undo. I guess the app must just check the user string to determine what OS I'm working on. I'm curious whether that'll also work on less common operating systems.
- Accessibility is obviously nonexistent, but the position of multiple Qt developers I've talked to is that this is apparently the browser's fault, not theirs. Still worth bringing up though, none of these apps are ever going to be compliant with A11y standards.
I'm leaving out any of the bugs I'm noticing with collision detection or resize performance, and just pointing out the issues that would be immediately fixed, for free, by rendering to HTML.
Also as a quick sidenote, stuff like broken scrolling isn't an "issue" in quotation marks. It's just a bug. I don't think you can chock something up like "my mouse scroll wheel should work" to a user preference. In the same way, you can blame accessibility problems on whoever you'd like, but a text editor that's impossible for a blind person to use is a real issue.
Looking at the sliders in the sidemenu example (http://qt-webassembly.io/designviewer/#SideMenu.qmlrc), they look like QT sliders rather than anything OS or browser native.
I predict this will be what news sites are built on a few years from now in order to "protect" their content.
Hopefully the need to be discoverable by search engines will mean that most sites will still use the dom, but at some point Google might provide a proprietary crawling interface...
"Please try out the Qt Design Viewer, but keep in mind that this is a technical preview. Bugs and issues can be reported here. The viewer application is fully open source."
So bugs are expected.
It's not enabled in the properties of the elements by default, so it's not selectable by default because it's a GUI, not a web document. Web developers have forgotten what an app is while trying to write apps by using tools meant for Web documents.
There was a TextEdit example where you select text.
I do agree there is some potential for misuse here but that's pretty much true of any web based tech in the last couple decades.
It is nowadays called Animate and it also supports AOT compilation to native code, including iOS deployments.
Oh, come on. Are people building full websites in Animate, like we used to in Flash?
Even “export to canvas/svg” features haven’t caught on. Most web banners I see are being hand coded.
What precompiled Animate iOS smash hit have seen on the App Store lately?
How many copies of Animate (excluding the “All Apps” plan) do you think Adobe sells (rents)?
I’d go the other route: Flash just isn’t dead in the minds of pro-Flash crowd.
As part of the pro-Flash crowd I am happy that Animate is not the only option, we have Blazor, Unity, Qt and plenty of other stuff in the process of taking advantage of WebAssembly, WebGL and eventually WebGPU.
The Pandora box is already open.
Do you have links to great content being created on this platform?
html5 was supposed to bring all the cool things Flash had without most of the annoying things I mentioned above. I saw some cool tech demos years ago, but for whatever reason (lack of good artist tools?) I haven't really seen much in years.
Yeah, this is so great. I love how when Chrome updates the first time I hear about it is when people are calling me because some website they rely on is broken by some arbitrary change.
Does someone know if WebAssembly support is available on the open-source Qt?
Also: is it one of those features that is a pain in the ass to set up from CMake instead of QMake?
Remember that WA lives in a black box with nary any access to networking, other APIs etc. and communication in/out of the block via shared memory is very, very low level.
QT is still heavily reliant on QMake in reality, but that should be a small part of the decision equation.
it is. I know that on windows the toolchain is available directly from the online installer, but I think that it isn't on linux. It's a quick build however :
git clone qt5 https://code.qt.io/qt/qt5.git
cd qt5
git submodule update --init qtbase qtdeclarative
mkdir ../build
cd ../build
../qt5/configure -xplatform wasm-emscripten -nomake examples -nomake tests -opensource -confirm-license -prefix /opt/qt5-wasm
make -jwhatever && make installSource: https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
Granted, it's closer than Swing. That's a pretty low bar. We need to either start qualifying this ("it's a good GUI toolkit for a cross-platform one"), or accepting that this is a scale (10 is "actually native", 0 is "just looks like Motif everywhere"). I'd give Qt 8/10 -- it's pretty good, and the screenshots look great but after a moment using it I'll say "wait, I think I know why everything feels just a little bit off".
even Microsoft OneDrive ? even battle.net ? even your AMD drivers ? even Telegram ?
> Why pay to develop for a particular platform?
Because Qt is not a particular platform but one of few cross-platform GUI framework.
Qt runs on Windows, Linux, macOS, iOS, Android, WinRT, VxWorks, QNX and others. [0]
You don't get one platform, you get just about all of them.
I’m not a fan of Qt or C++, but I will admit it is at least a very pragmatic and efficient choice for Linux GUIs. It’s much less than that on mobile.
Electron is eating a bit of their lunch but it lacks a few features yet, uses a lot of resources comparatively, and doesn't support the same targets or developer communities that Qt does.
It's not expensive is you have a business that makes any money. It's free if you don't modify qt source itself and follow LGPL.
How well does this play with web searches? Do I will be able to find a Qt application searching for words on its interface? Do we need a store like https://addons.mozilla.org/ to find the content?
And, mainly, is this going to substitute all web information or just will move desktop apps to the web?
I would like that documents continue being documents, and applications should be applications. But, like with Flash, many people may disagree on that point.
I use and like Qt, but I also think that documents should be just documents - without gratuitous JS framework bullshit.
Additionally, can these sites be responsive such that the content will look good on desktop and mobile?
[0] https://arstechnica.com/uncategorized/2008/08/target-to-pay-...
Error: Out of executable memory in function at index 31948
QML simply lacks a lot of features, and C++ hooks are often required to make it work well.
Oddly, you need to launch a QML app using at least a little bit of C++ no matter what. That's not a problem for mot pro devs who can hack a little bit of C++, but it's actually problematic for most others. Even 10 lines of C++ is too much for most devs who don't know it. It's like having to speak 10 lines of Russian. The docs are often tricky and ambiguous about how to start and launch apps as well.
Not qt is trying to do basically same what Macromedia did with Flash. Enable rich binary components on a web, with exactly same issues Flash had.
Don't take me wrong, webassembly is great, so is qt. Maybe you can create very specialized electron app with that, but please don't overuse it for generic web content.
That was lost the moment the powers to be, decided it should compete with OSes as application platform.
I would like to see a future where you can just open a WASM file in the browser and it will compile/render to the screen as an application. This would alleviate the pressure put on html pages to behave as if they're something they're not. It would let html go back to, as you say, its core responsibility, which is to be an interactive document.
I can count on one hand the number of native apps I use that couldn't have their interfaces trivially represented by HTML and CSS.
If you're not building Blender, Photoshop, or Maps, odds are pretty good that your native app is just a document. And even in the case of apps like Photoshop, only the main view is special -- everything else is just menus and toolbars.
People draw a hard line between a document and an app, and I've just never been able to see that line.
P.S. Just in case it does sound like it - no, I'm not trolling. That ^ is a genuine question.
If I can translate your application's current state to an org-mode document (or any other hierarchical document format) without losing any significant information, then your interface is an interactive document. Maybe your backend is better suited for C, or needs native capabilities or something. I don't care about that. The actual interface itself is just hierarchical information.
HTML is just a way of organizing information into a tree. It's not a layout tool (even though some web devs treat it like one), it is a display format. CSS is the incidental styling that gets applied on top of that format.
For example, I have KeepassX sitting open in front of me. It has a row of buttons on the top, a tree view, and a currently selected record in a table.
Very roughly, the HTML equivalent of that is:
<ul class="toolbar">
<li>Open Vault</li>
<li>Save Valut</li>
<li>Add Record</li>
<li>Edit Record</li>
<!-- etc... -->
</ul>
<ul class="folders">
<li>My Passwords</li>
<!-- etc... -->
</ul>
<table class="entries">
<tr>
<th>Title</th>
<th>Username</th>
<th>URL</th>
</tr>
<tr data-selected="true">
<td>Some Site</td>
<td>danshumway</td>
<td>somesite.com</td>
</tr>
</table>
So now I try to resize KeepassX, and when it gets to below about 400-450 pixels, it refuses to get any smaller. It's not responsive. This is because it was written in some native format that was only thinking about grids and pixel-perfect positioning, and the idea that rendering content was a different concern than rendering style never occurred to anybody.
A number of native formats like GTK already use XML to lay out their interfaces. The only difference is that they're using XML as a layout tool and not as a display target. But for an app like KeepassX, rendering to an XML-like format would be a strict improvement over whatever the heck it's doing now.
The browsers themselves together with the companies that drive them, killed the web on its conceptual level, and now the browser is just a multi-platform engine to render apps that are located in remote servers (and lets not forget how they will push for cloud stack here, given the profits it will make for them).
The web got corrupted into its core concepts, and now is just a shadow of its former self.