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
off).
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
replacement.
-- Elliot
I don't actually know what the plans are regarding the view world, Imainly 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).
IIUC, Aura is the replacement window manager for chromeos. You may
> Or does it make sense to go with the Aura port that Mandeep is
> pursuing - is that applicable for a standalone desktop browser?
want to use this *anyway* since the plan is to Composite ALL the
layers!, but its design goals are to be a desktop environment
replacement.
We still compileagainst 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
off).
Since that bug was open, I believe we now target 2.18.
> Is this the right time to start this effort? Would you be willing to
> review such change sets?
If you were to create some sort of compatibility header mirroring new
methods that did the equivalent of:
#if GTK_CHECK_VERSION(2,20,0)
inline int gtk_get_something(GtkWidget* something) {
return something->break_seal_for_something;
}
#endif
and start moving parts of our GTK code so it compiled with struct
seals, I'd be grateful!
There's a lot of work to just get through the preparation we can do
while on GTK2, but...
> Following that do you think it's possible to enable gtk3 via a compile flag?
I really doubt it. Things are going to be way more complicated than
that! Just taking a look at
http://developer.gnome.org/gtk3/3.3/gtk-migrating-2-to-3.html ,
chromium hits most of those points.
- Most widgets that can display to the screen connect to the expose
signal and would have to be ported to the new draw signal.
- Most widgets muck with the size-request/size-allocate.
- A quick grep shows we use GdkRegion, GdkPixmap, GdkColormap,
GdkDrawable, and GtkObject at least some places in our code. (We
mostly use cairo for our drawing though.)
- We use low level event filtering to do some of our X11 tricks.
- Not mentioned in that document, but parts of our gtk theme
integration code call low level draw commands to the theme engine.
Take a look at chrome/browser/ui/gtk/gtk_util.cc:DrawTextEntryBackground()
for an example. I'm not sure if this is a problem or not.
So yeah. Lots of work to do here. I was planning on not bothering with
any gtk3 porting work until the next Ubuntu LTS dropped (since I'm a
bit swamped with other linux work), but there's actually a lot that
someone interested could do now to make the porting effort go quicker.
As a few hints, don't bother with any gtk code under ui/views/ or
chrome/browser/chromeos/. That code is chromeos/views specific should
be going away Real Soon Now.
-- Elliot
FYI:
http://codereview.chromium.org/8588068/ - Start of a compatibility header
http://codereview.chromium.org/8586044/ - Don't include single headers.
-- Elliot