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?
