[Webkit-unassigned] [Bug 19392] [Gtk] Enable WebInspector in the Gtk port

[bugzilla-daemon at webkit.org]

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





------- Comment #14 from gns at gnome.org  2008-07-16 04:19 PDT -------
(In reply to comment #13)
> (From update of attachment 22282 [edit])
> This is slightly wrong, when "destroy" is emitted it's already too late for
> saving the window, the only remaining option is to reparent the widget.
> 
> Would it be too complicated to work around the issue of a destroyed web view on
> the WebKit side? It should be possible, to unset the view via
> gtk_widget_destroyed and request a new web view as needed, shouldn't it?

I thought about doing it that way, but I can't remember why I decided going
with the already existing WebKit 'workflow' would be better. I can implement
that; I believe it would feel more natural indeed.

> Could the documentation be a little clearer? To me "attaching to a window"
> doesn't intuitively make much sense.

I decided to actually implement this signal because the 'attach' and 'dettach'
commands are in the Inspector's HTML, and I'm not sure we will want to deviate
from that UI.

I'm not sure how to improve that documentation, though. Perhaps something like
'Emitted when the inspector should appear at the same window as the
#WebKitWebView being inspected.'?

> I suggest an URI property instead of a signal. The current patch doesn't seem
> to do anything with the boolean return value anyway.

That works for me. I added the boolean return values on everything to let the
user create a number of signals, and decide on one of them to be the last.

> The boolean return value isn't used at all. Would it make sense to use
> GtkObject, gtk_object_destroy and "destroy" here? If not, what about
> s/inspector-destroyed/destroy, which is obvious enough as I see it.

I think the name change is in order, but I'm not sure about how I'd use
GtkObject.

> What about s/inspector-web-view/web-view, since it's probably obvious enough.

oki!

> Do we need all those defaults, most of which are empty placeholders?

I am mostly mimicing WebKitWebView, which does have such empty placeholders,
but I was on the brink of removing them. I was just worried that then we'de not
have the members in the class structure, and may have problems if we want to
add them later. I'm all for removing, though.

> The property ought to be "web-inspector", right?

Yeah, my bad.

> Looking at the code I see the use case of the WebInspector class and I think
> it's actually a good idea. I imagine you can keep one application wide instance
> around like you can with the WebSettings.

Right now you can't, since I intentionaly bound the creation and relation of
the WebInspector instance to the creation of WebView, and provide no setter,
only a getter, but that does look like a good thing to have. Coupled with the
first modification (handling the Inspector WebView destroying) this would make
the WebInspector very natural to use. I'll be quite busy at work and other real
life issues today, but I'll try to have a new patch with most comments
addressed by tomorrow night.

Thanks!


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