Monday, September 22, 2008

Drafting a browser

After my latest post about Google Chrome, I was pondering how to use the process separating system on other projects or making a own browser with the same idea. Fortunately I found that there's GtkSocket and GtkPlug. With them you can easily embed other processes on a main process.

So we need a main application, which creates tabs and takes care of handling them. Quite easy job to do. When creating a new tab showing a new GtkSocket inside it. Socket id is passed to a new process, for example by launching a new process with exec and passing socket id (numeric value) as a command line agument. That's about the minimal required functionality for the main process. It just handles tabs and launches other processes.

The client application reads the numeric socket id from it's command line arguments, creates a new GtkPlug with gtk_plug_new (socket id as a parameter). Now it can just draw any Gtk+ widgets on that GtkPlug widget and show them. So now we can draw, let's say, a URL bar and for example WebKit/Gtk on that GtkPlug widget. And let's define some signals that when typing URL on the URL bar the URL will be opened on the WebKit/GTK. Now the client app is ready.

And what do we have now? A main app, which opens tabs, launches a client app and passes GtkSocket id for it. Client shows URL bar and WebKit. The contents of client app is shown inside the main app's tab view. Isn't that now a simple web browser, where every tab is running it's own, separate process? Somebody could now catch the idea and continue working on this kind of approach. And that's not just browsers. The GtkSocket is normat Gtk+ widget, which can be used like any other widget. One could make very interesting apps where one main app embeds other processes inside it and showing their content. Now anybody got some ideas? At least I do...


inz said...

I guess you've never ran into the problems of Xembed (as used on X with GtkSocket/Plug). Everything goes quite allright, until you want to add a keyboard shortcut to your main program. You press the button, and... it goes to the embedded window; always. Only way around is to add massive glue code that forwards the events using some method.

While yes, process separation is a really nice thing to have (if you have enough memory ;), Xembed, however, might not be the way to go.

Dieter_be said...

Maybe you're interested in the uzbl browser: