[Webkit-unassigned] [Bug 17154] [GTK] Widget size negotiation

Mon May 9 06:26:49 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=17154

--- Comment #15 from Gustavo Noronha (kov) <gns at gnome.org>  2011-05-09 06:26:49 PST ---
(In reply to comment #14)
> My objection is that a user should be able to pack a widget in any of the containers that GTK+ provides and have it play nice. Right now a WebView widget can only grow in anything other than a GtkScrolledWindow. That seems wrong, but I may just misundertand GTK+ here. I also think requesting thousands of pixels during size-request might be causing some performance issues in certain containers. Other ports do not try to grow their widget as large the document content, instead they let the widget itself determine the size of the viewport. Perhaps I'm wrong about the entire thing though.
> 

I think the other ports do it like that because they pretty much rely on WebCore painting the scrollbars. The idea of having WebKitWebView be a similar to GtkTextView from the beginning, and act as a regular GTK+ widget as much as possible is what led to this decision.

> For GTK+ 3 we are setting both the minimum and natural sizes to the size of the DOM document.

Makes sense to me to have minimum be 1x1 on the GTK+3 case, fwiw. GTK+3 is much more amenable to the requirements of a widget like ours =)

> Usecase: Imagine wanting to pack a WebView (sans GtkScrolledWindow) with a fixed size into some container along with some toolbars. Seems like a pretty reasonable usecase. Right now you can't do it without manually overriding the size-request signal.
> 

Makes sense. I'd argue though that the main use case has been packing it inside a ScrolledWindow, so that should be the default one to be supported.

> Honestly though, my real usecase is allowing WebKit to draw and control the main frame scrollbars itself. I'm was very close to having this when I bumped into this bug. I would like to support having main frame scrollbars with and without the GtkScrolledWindow wrapper. This is the only way we will remove the scrollbar race conditions, which plague many of our tests and turn our bots red.

YES! I think it should be the default mode for Web browsers, like I already said, letting WebCore draw the scrollbars would make web compatibility much better. Just to document what we discussed on IRC: if we can make it a second widget it'd be perfect in my book. It should be simple given we can make it a subclass of WebView, so there would not be a need to change too much, but I could also agree to making it a setting.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.