Qt WebBrowser 1.0 | Hacker News Reader

Qt WebBrowser 1.0

blog.qt.io

161 pointsmkesper39 comments

KDE was based around Qt and their rendering engine, KHTML became Webkit, which is a core part of Chromium. So Qt are using embedded Chromium, I wonder if there is any duplicated code in the repo now?

These days Chromium use Blink, a fork of Webkit. I am unsure how many, if any, changes to Blink is ported over to Webkit.

Confusingly same name as this old portable browser I sometimes use.

http://www.qtweb.net/

I use this humble little browser almost daily, to test that the web app I'm working on can run inside QtWebKit windows of desktop applications (mostly for making sure that I have all the necessary polyfills and vendor prefixes in place).

I use it everyday for sites that block adblock; It has built-in adblocker;

Interesting, but sadly it has no way to redirect popup windows to tabs.

Wonder if this will be kept up to date with the Google repo security-wise. That might be the Chrome-sans-Google people were waiting for.

How is this more "Chrome-sans-Google" than Chromium itself?

IIRC Chromium still requires significant patchwork and build time flags to fully disconnect it from the mothership, the engine itself has no such dependencies

Can you sign into a Google account and leak all your personal data to Google using chromium?

If so, why are you even asking the question?

How often is Linux used these days in embedded devices (non-android)? In the past Windows driver support was so much better that Linux generally didn't have much of a payoff.

Very often. Vendors such as NXP/Freescale, TI, Intel (and Chinese manufacturers on top of MIPS) all tend to target Linux-first. For some drivers (e.g. wireless), you sometimes need to work directly with that vendor (Qualcomm/Broadcom/...). In my experience, it is almost the default except in cases where you need 1) Hard real-time, 2) Very low power (most battery applications), 3) Very low cost. Those still go to MCUs where life is more difficult for anything complex (e.g. requiring graphics, a network stack).

For most embedded use cases, Android is still not suitable as you have to jump through many hoops to get sufficient control over exactly how the device operates (you can make it work but the further away your device is from a phone/tablet, the harder it gets).

Source: Worked in embedded design services until recently.

I have a forecast picture for you http://eecatalog.com/automotive/files/2013/11/IHS_fullsize.j... it's a couple of years old (from 2013) but as far as I can tell it's definatelly going in this direction in the car industry at least.

If the embedded device needs IP connectivity and it doesn't have any hard real-time needs, it tends to run one of the many forms of embedded Linux.

So, yes... its pretty popular. In fact, its the default choice for most things.

Considering the convergence between tablet style devices and embedded devices (in car systems, in flight systems etc) and the fact the car industry seems to be standardizing towards Linux probably a lot more than it used to be.

Embedded stuff doesn't have the same life cycle turnover rate as consumer stuff though so the push will be fairly gradual.

How far in the past are we talking? In the embedded devices I've worked on, Windows was never a consideration because trimming it down enough was a major concern, and as were licensing costs. Drivers, on the other hand, rarely came up as an objection to Linux - it doesn't take much volume before writing Linux drivers was the cheaper option, and if you have control of the hardware platform in the first place, picking options that worked well with Linux was easy enough.

That said, it's 16-17 years since I did much embedded work.

There's Sailfish, and it's based on Qt precisely. And Jolla is a Finnish company, just like the Qt Company.

So they have a partner using their technology, it is that weird that the browser works on that platform first?

Really? I would disagree. Linux really only falls behind on graphics drivers, at least from my experience.

I suppose this being qt, that's probably what you are talking about.

Graphics drivers are a big one. But things like touch screen drivers can be a problem.

I haven't looked at the situation since 2011, so I'm not up to date.

>But things like touch screen drivers can be a problem.

Android has helped a lot in this regard. While still not perfect, it's definitely much more mature.

Touchscreen drivers are pretty much a commodity now. You see a lot of the same manufacturers over and over (Atmel, eGalax/EETI, FocalTouch, TI, etc).

The problem is that every hardware designer hooks up a different GPIO line for the touch interrupt signal and so you're deep into the kernel to hook that all up.

Devicetree has made this lot easier now, though. Then you have smaller issues like setting up calibration and TSLIB/filtering files, but that's a lot easier than it was five years ago. Multitouch can still be hairy depending on the target O/S.

I always thought that Linux was actively avoided in embedded systems such as ATMs, Medical or Industrial Equipment, because the GPL forces you to release your source code.

That's a really old myth. Only if you intertwine your code with GPL code, use a GPL library, or modify GPL code do you need to release anything you write yourself. It is very very easy not to do any of those things.

One gray area (gray because two camps both think it's black and white in opposite directions) is writing any code that runs in kernel.

It's a problem with GPLv3, but for most other open-source licenses (e.g. BSD MIT) it isn't.

Is it just me or is their homepage (http://qt.io) completely broken?

I can't believe the level of sarcasm and vitriol this is getting. Someone messed up! A bug that happens under specific circumstances that probably aren't being tested for (screen size above X) showed up. Happens to the best of us! The folks who work on the website probably aren't even the same folks who work on the toolkit. And what even if they were? Does that erase the awesome product they created? Sometimes the lazy negativity on the internet bothers me to no end.

At the time of this writing, there are 14 comments nested beneath the parent.

Two are mildly sarcastic ("probably something you might want to check", "welcome to mobile first").

A handful that simply state "the site's broken".

The Internet can be a harsh place sometimes, but you should consider the possibility that you're being hyper-sensitive. There's really nothing here.

Narrow your window. For some reason it only works on 'medium' width.

Probably something you might want to check if you have the following tagline: "A modern user interface that is beautiful on every screen and performs perfectly on every platform is not an option, it’s a necessity."

Maybe they only tested it in the Qt WebBrowser (I'm only half-joking - it seems to work on "narrow windows", which would be in line with the type of devices on which this browser is supposed to work).

That's a very weird oversight. Can't believe no one caught that.

Their webpages are constantly moving, changing and breaking. The domain itself has moved 4 times in 4 years. There's just incredible churn on that side of the project, unfortunately.

Same here. On Desktop, Firefox - it's broken with maximized window. After you reduce the window size to a certain level, the images appear instantly.

Sites breaking on desktop is so bizarre, it's like something that shouldn't even be happening since HTML's base defaults work for it.

Pretty broken. I gave up finding a download link for the compiled windows bins after 5 minutes.

https://www.qt.io/download-open-source/#section-2

The first step is the installer asks you to sign up or login. Thankfully there is a "skip" button.

It's Chrome that's broken, so you'll try QtWebBrowser /s

Welcome to "mobile first"!

It's broken.

Reply on news.ycombinator.com