Adam points out that while we're at it, it's unclear whether we can use gtk in a sandboxed renderer so we ought to figure out the ultimate target with form control rendering before we do this.
This was previously discussed a bit here: http://groups.google.com/group/chromium-dev/browse_thread/thread/9ea553d8362b5cb8 Options as I see 'em: 1) Figure out whether we can make Gtk happy to run without a display. I had a conversation with one of the Gtk authors about this, see comments below. 2) Use built-in WebKit widget theming. Again solves the "which native theme to match" problem by pissing off everyone equally. Easy to implement: Hyatt says we just make a stub RenderTheme which returns false everywhere. Makes our (in particular) scrollbars look wack. Adam tried this out and got something that has flat-shaded widgets in about 10 minutes; would require work and art. 3) Render widgets browser-side and proxy the rendering over IPC. Sounds gnarly to implement; is a superset of our current set of hacks. 4) Some other approach lets us still have an X connection and sandbox. Would be also useful for sandboxing Flash, not that we do that already. Strawman proposal: use Xvfb. Or perhaps the X security extension would cover this: http://www.xfree86.org/current/security.pdf . I chatted with a Gtk developer about this situation and he sounded very unhappy with the amount of hacking that's already necessary to get this to even work when we *do* have a display (e.g. like what Firefox is doing right now). After some back and forth, he ended with: "Honestly, I'd say pull some color out of the GTK+ theme, 1), make your product look good in its own way, then wait for themes to be fixed." That is, pull the colors out in the main process and pass them to the renderers. Reportedly they're having a hackfest in this area in the next few months, so maybe the situation will have improved by 2010 or something. So he joins Adam in advocating option 2, which was also advocated by some of the Qt folks, which makes me think it's our best option. However, doing so will require custom artwork for our buttons and such, and I don't know who that should fall upon. In any case, we should hold off on my suggestion below until we figure that out. On Tue, Feb 10, 2009 at 9:04 AM, Evan Martin <[email protected]> wrote: > Historically on Windows we had a "layout test mode" flag which would > tweak some settings to make our layout test output match the WebKit > mac baselines better. However, this means that we weren't testing the > code we were running and I believe all that code is gone now. > > On Linux, since layout tests were all we had, we've gone the route of > effectively hard-coding in a layout test mode. We should undo this > now that we're passing a reasonable fraction of tests. But we're > going to need to do a couple of painful rebaseline-the-world steps > where we create new expected images. The two big ones I can think of > are > - antialiased text (this is a one-line code change) > - proper scrollbar rendering (we currently render a gap near the > arrows; probably involves reading some WebKit/Gtk code) > > Who would be good to do this? It needs someone who can be careful to > not check in bad baselines. > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
