Closed GoogleCodeExporter closed 9 years ago
Original comment by james...@gmail.com
on 7 Jun 2008 at 1:17
We'd appreciate if someone can help on it.
Original comment by james...@gmail.com
on 7 Jun 2008 at 2:09
I'm working on this now. But i'm not sure if this is dependent on Bug #151.
Original comment by jmalo...@gmail.com
on 10 Jun 2008 at 4:27
Great news!
There is no dependency between JavaScript runtime and browser element. What
your are
working on would be a browser element similar than
extensions/qtwebkit_browser_element and gtkmoz_browser_element, which depends on
WebKit/Gtk+. The browser element is mainly for supporting iGoogle Gadgets and
HTML
details view.
Original comment by james...@gmail.com
on 10 Jun 2008 at 5:20
Hi James
Thanks. Is there a way to find out, at runtime, if i'm *really* using a
different browser element?
Original comment by jmalo...@gmail.com
on 10 Jun 2008 at 5:52
Currently the module name of browser element is hard coded in host's source
code.
Please look at hosts/gtk/main.cc and hosts/qt/main.cc.
So the host always knows which browser element implementation is currently used.
Original comment by james...@gmail.com
on 10 Jun 2008 at 5:57
Hi James
Thanks for your feedback. Attached is a patch to add a webkit browser element.
There's still a couple of FIXMEs which I'm hoping you can answer.
1. I'm sharing DecodeJSONString with Qt. Is there a place where to put shared
code
across port/host/browser_elements?
2. I'm loading the decoded JSON string as us-ascii. Is there a way to get the
encoding of the string?
Thanks and appreciate if you can review the patch as well.
Regards
Jan
Original comment by jmalo...@gmail.com
on 10 Jun 2008 at 7:08
Attachments:
Thanks for your contribution. We'll review your patch and give you feedback
asap.
Original comment by james...@gmail.com
on 10 Jun 2008 at 8:00
The patch doesn't quite work yet. But any feedback is definitely appreciated.
Thanks.
Original comment by jmalo...@gmail.com
on 10 Jun 2008 at 8:06
Some quick comments:
1. Coding style
We usually use two space characters for indent, and the maximum line length is 80.
2. In configure.ac
following lines are not necessary:
+else
+ WEBKIT_LIBS="$WEBKIT_LIBS"
+ WEBKIT_CFLAGS="$WEBKIT_CFLAGS"
+ AC_SUBST(WEBKIT_LIBS)
+ AC_SUBST(WEBKIT_CFLAGS)
3. The pc file name of WebKit/Gtk
In openSUSE, the file name is WebKitGtk.pc. I'm wondering if there is a
standard one.
I'll give you more feedback later.
Original comment by james...@gmail.com
on 10 Jun 2008 at 8:20
Hi Jan,
I tried your patch on Ubuntu8.04, The browser_element rendered nothing. I got
errors
like below:
42:05.271: ../../../ggadget/gtk/single_view_host.cc:267:
SingleViewHost::EnableInputShapeMask(true)
42:05.559: ../../../extensions/gtkwebkit_browser_element/browser_element.cc:131:
Layout: 1.000000 1.000000 298.000000 248.000000
(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_widget_reparent: assertion
`widget->parent
!= NULL' failed
(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_fixed_move_internal: assertion
`widget->parent == GTK_WIDGET (fixed)' failed
42:05.564: ../../ggadget/small_object.cc:584: FixedAllocator Stat: 16 30000
14930
15070 60 0.984967
42:05.606: ../../ggadget/small_object.cc:584: FixedAllocator Stat: 16 30067
15000
15067 60 0.984771
42:05.736: ../../../extensions/gtkwebkit_browser_element/browser_element.cc:131:
Layout: 1.000000 1.000000 298.000000 248.000000
(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_widget_reparent: assertion
`widget->parent
!= NULL' failed
(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_fixed_move_internal: assertion
`widget->parent == GTK_WIDGET (fixed)' failed
42:06.093: ../../../extensions/gtkwebkit_browser_element/browser_element.cc:131:
Layout: 1.000000 1.000000 298.000000 248.000000
(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_widget_reparent: assertion
`widget->parent
!= NULL' failed
(lt-ggl-gtk:17154): Gtk-CRITICAL **: gtk_fixed_move_internal: assertion
`widget->parent == GTK_WIDGET (fixed)' failed
42:06.480: ../../../extensions/gtkwebkit_browser_element/browser_element.cc:131:
Layout: 1.000000 1.000000 298.000000 248.000000
Original comment by idlecat...@gmail.com
on 11 Jun 2008 at 9:46
Hi James
3. The pc file name of WebKit/Gtk
In openSUSE, the file name is WebKitGtk.pc. I'm wondering if there is a
standard one.
The old qmake build used to build a WebKitGtk.pc but since we moved to
autotools (a few months ago), this
has been renamed to webkit-1.0.pc.
idlecat511,
Yeah. I realized it doesn't work at all. I'll try to come up with a patch
sometime this week or next. Thanks for
trying it out.
Feedback appreciated.
Original comment by jmalo...@gmail.com
on 11 Jun 2008 at 11:26
In order to make browser element work properly, signals "onGetProperty",
"onSetProperty", "onCallback" and "onOpenURL" must be implemented. Please refer
to
the source code of gtkmoz_browser_element.
The qtwebkit_browser_element hasn't implemented them yet.
Original comment by james...@gmail.com
on 11 Jun 2008 at 12:06
Attached is an updated (and tested!) patch. It doesn't contain implementation
of the
signals James mentioned in the previous comment (yet). Is there anything else
I'm
missing?
Cheers
Original comment by jmalo...@gmail.com
on 12 Jun 2008 at 4:59
Attachments:
Hi Jan,
I've just tried the patch. It works great. But without the signals James
mentioned, a
lot of functions are not there. For example, your browser element can't load a
page
with an external browser.
--
Tiger
Original comment by idlecat...@gmail.com
on 20 Jun 2008 at 2:57
Hi James, idlecat511
Where can I find documentation of those signals? What should the implementation
do?
Thanks.
Original comment by jmalo...@gmail.com
on 22 Jun 2008 at 11:30
We have no direct docs for the signals, but you can see related documentation in
extensions/gtkmoz_browser_element/browser_child.h about kXXXXXFeedback
constants,
each of which (except for kPingFeedback) corresponds each of the signals. At
least
onOpenURL signal should be implemented, but others are also required when
window.external is used in HTML details views.
Original comment by phnix...@gmail.com
on 23 Jun 2008 at 12:47
I just found that webkit gtk port 1.0.1 contains api to access JavaScript
context,
and ubuntu 8.10 already ships webkit 1.0.1 package. Now, it might be possible to
implement those signals.
Hi jmalonzo, can you please help update the implementation to support those
signals?
And I'm wondering if it's worth to implement a script runtime based on
JavaScriptCore, then we can get rid off the dependency to xulrunner completely.
Original comment by james...@gmail.com
on 21 Oct 2008 at 11:04
Hi James
Is there a reason why gtkmoz uses a gtksocket instead of just embedding the
widget
into a container? Is this the way moz embedders should work or it's just a ggl
design
decision? I noticed that gtkmoz and qtwebkit have different approaches and
wondering
which path I should take for gtkwebkit.
As for the script runtime, it would be nice if we can just use JavaScriptCore
for
webkit. Using xulrunner eventhough webkit's the engine is I think superfluous.
Original comment by jmalo...@gmail.com
on 23 Oct 2008 at 12:32
It's a design decision based on following reasons:
1. Gecko is huge, we don't want to pollute host's symbol table by linking to
Gecko
dynamically.
2. It's easy to debug gtkmoz-browser-child separately.
3. smjs-script-runtime may be able to use different libmozjs than the one in
Gecko.
4. The ABI of Gecko is not stable, gtkmoz-browser-child might not work due to
ABI
incompatibility. We don't want it to break whole GGL.
I think gtk webkit doesn't have such issues, so taking the qtwebkit approach is
just ok.
For script runtime, I'm wondering if you are interested in writing a script
runtime
extension based on JavaScriptCore? Then we can get rid off Gecko dependency
completely, it's really awful, due to ABI compatibility issue.
Original comment by james...@gmail.com
on 23 Oct 2008 at 2:29
I think the main reason why I can't do OpenUrl yet is because there's no way I
would
be able to know if a link was clicked or if a new window's been requested.
There are
patches in the webkit bugzilla but not yet in the mainline trunk. Once the
patches
have been landed, I would be able to do this.
For the script runtime, I'll check it out. No promises though.
Cheers
Original comment by jmalo...@gmail.com
on 23 Oct 2008 at 9:46
This is just an update to the previous patch for it to apply cleanly with HEAD.
Cheers
Original comment by jmalo...@gmail.com
on 23 Oct 2008 at 11:10
Attachments:
I'm working on a script runtime extension based on WebKit/JavaScriptCore. Hope
we
will have a full webkit port soon (including this webkit browser element).
Original comment by james...@gmail.com
on 23 Feb 2009 at 6:38
full webkit support has been committed to trunk.
Original comment by james...@gmail.com
on 24 May 2009 at 1:23
Original issue reported on code.google.com by
jmalo...@gmail.com
on 7 Jun 2008 at 6:04