On Wed, Nov 16, 2011 at 10:48 AM, Rob Bradford
> I'm trying to work out the what direction a "desktop" port of Chromium
> to Wayland should take. By desktop I mean a standalone browser that's
> currently sitting on GTK/X11. Wayland is a display server architecture
> that can be used to replace the X stack - it's still early days but
> getting an application like Chromium working is a good test and also
> helps us with some of the chicken and egg problems that you face with
> a new technology.
That depends on what your goals are.
> A GTK on Wayland port - substituting any X11'isms with Wayland code
> and fixing and improving GTK's Wayland support to enable this.
If you're goal is to integrate into the current Linux desktop
(meaning: GNOME, Unity, XFCE, KDE, etc.), this is the obvious correct
choice. This requires quite a bit of porting though. We still compile
against GTK+ 2.18 because it's the latest GTK shipped in one of the
RHEL distributions (correct me if I'm wrong; I might be a version
If you want to look at some of our X11isms, look at
content/browser/renderer_host/backing_store_gtk.cc (it's mostly X11
code, but is only used by the gtk port). You'll notice we do a bunch
of stuff with XShmCreatePixmap and XShmCreateImage. I also added some
X11 extension using code last week (it's the part of that file that
tests and opportunistically uses an XSyncExtension alarm to queue up a
bunch of drawing commands and have our alarm fired when done instead
of blocking our UI loop with an XSync()). There's also a bunch of
stuff in media/ that directly uses XRender that I have no idea about.
IIUC, wayland support won't be backported to GTK2; so we would first
need to do that porting. We break a lot of GSEALs. We also do a
surprising amount of stuff at the GDK level, and we can't start this
porting on trunk because the version of GTK we target is so old, it
doesn't have accessors for a bunch of the things we break GSEALs for.
Lots of unknowns here.
Also, flash is still linked with gtk2 and thus X11. We might be able
to get around that with some sort of nspluginwrapper like thing that
also proxies X11 calls, but ick!
> A pure views based approach - where there is a NativeWidgetWayland
> implementation to back the views - a lot of this code was already
> implemented by Daniel Nicoara.
I don't actually know what the plans are regarding the view world, I
mainly work on the GTK port. That said, the chromeos people are hard
at work removing GTK from views (though still depending on glib) and I
would expect that this configuration could work for you if you don't
care about the browser integrating with the desktop (theme stuff,
various gnome/xkce/kde integration and I think even XDG style stuff
though I'm not sure).
> Or does it make sense to go with the Aura port that Mandeep is
> pursuing - is that applicable for a standalone desktop browser?
IIUC, Aura is the replacement window manager for chromeos. You may
want to use this *anyway* since the plan is to Composite ALL the
layers!, but its design goals are to be a desktop environment