The UI component of it is ugly as hell, and the API style is a little antiquated. It also isn't as comprehensive as Qt, and there isn't as many resources out there for it.
I worked for a high end audio company and used it in one of their acoustic simulation softwares.
One of my main jobs was porting this project to Qt.
Qt is a higher-level application dev framework with UI support (like MFC but cross-platform). We were looking for lower-level constructs - especially in the networking and P2P areas.
I know that you are an ex-chrome dev so this is all moot as Chrome is the code you knew when you started, but really that is exactly what QtCore + QtNetwork is for. You don't have to use any of the GUI bits when you use Qt if you don't want to. I have written many "Qt" applications that were console apps simply to use the built in capabilities.
Edit: in fact just to highlight how similar it is, the way that QtWebKit works is that it is built on top of these modules in a [hand wavy] similar way that blink is built on top of the chrome development platform (I have hacked on Qt, WebKit, and Chrome).
> Qt is a higher-level application dev framework with UI support
Qt is a C++ application framework, it has both low- and high-level components, much like e.g. Cocoa.
> We were looking for lower-level constructs - especially in the networking and P2P areas.
Which Qt provides. Qt is modular and Qt has plenty of low- or intermediate-level modules, including extensive networking, storage and concurrency systems. Using Qt does not mandate using Qt's UI components.
Qt is reasonably separated into modules; I've deployed stuff that only depends on QtNetwork, QtSql and QtCore and all the other stuff doesn't get linked in (it's not even in the #include search paths).
(I haven't used Chromium libs and have no opinion about them)
Hell, Emacs meets those requirements. I'm half-serious too: org-mode and Gnus are nice pieces of software that don't have anything to do with text editing per se.
There are a lot of cross-platform base libraries out there, many of them (like Qt, GTK/GLib, and Mozilla's stack) well-documented and well-supported. These systems are meant to be reused; Chrome? Not so much. Besides the buzz factor, why would you want to base a product on Chrome instead of one of the codebases designed to be used that way?
Isn't that what Qt is for, with the added bonus that it's what Qt is actually for and thus e.g. documented and supported?