i've worked with webkit a *lot*. for example, i helped denis with the port of webkit to directfb. in doing the python-webkit (direct) bindings http://www.gnu.org/software/py... i covered a *lot* of different ports of webkit. here's the summary:
* when compiling the standard webkit to run on a 400mhz ARM9, the gtk port started up in around... i think it was somewhere around 8 seconds. this was tolerable. it used about 130mb of memory to load a single basic page.
* when compiling the DirectFB port to run on the same system, it started up in about 3 to 4 seconds, and used about 1 or 2mb less memory. this was great!
* when compiling the Qt4 port to run on the same system, it took NINETY SECONDS to start up, consumed DOUBLE the amount of memory, and was basically completely intolerable.
the directfb port basically used an older (revision 1.2) version of the lite toolkit. to say it's light-weight would be an understatement: it's absolutely awesome. qt4 has unfortunately turned into a bit of a monster. gtk by comparison has remained reasonably level-headed, and when it (finally!) has the equivalence of COM's co-classes added to the gobject introspection layer gtk will become highly significant, strategically.
so anyway, the point is: there are lots of ways this can be achieved. you can implement the window manager externally and treat the browser as an isolated "component". you can go the other route and implement the window manager *using* the browser engine. but the main point is that either way, gtk and qt4 are to be honest complete overkill. it's only when you have things like co-classes built-in to the underlying infrastructure (like COM has) that you get any _real_ flexible benefit from the widget set, and as neither gtk nor qt4 have those, there's honestly really no point having them around.