41
edits
Gtkmozembed: Difference between revisions
Jump to navigation
Jump to search
Minor fix in →Introduction
(Add mailing list to →Introduction) |
(Minor fix in →Introduction) |
||
| Line 1: | Line 1: | ||
== Introduction == | == Introduction == | ||
[[http://www.mozilla.org/unix/gtk-embedding.html GtkMozEmbed]] is an embedding API designed many years ago for use in Gtk applications. See also [[http://lxr.mozilla.org/seamonkey/source/embedding/browser/gtk/src/ source code]] | [[http://www.mozilla.org/unix/gtk-embedding.html GtkMozEmbed]] is an embedding API designed many years ago for use in Gtk applications. | ||
See also [[http://lxr.mozilla.org/seamonkey/source/embedding/browser/gtk/src/ source code]] | |||
Gtk is built around Glib signals and has a fixed C structure method dispatch design. GtkMozEmbed unfortunately isn't perfect and was designed with basically a single object to represent the entire browser of its time. This didn't scale well and unfortunately wrapping each and every object in Gecko is unreasonable. It is conceivable that someone might someday make a Glib-connect XPTCall layer or something like it that could proxy between XPCOM (or its replacement) and Glib. The main advantage of doing this is that no person would have to manually spend time writing bloaty wrappers for each and every imaginable Gecko object. | Gtk is built around Glib signals and has a fixed C structure method dispatch design. GtkMozEmbed unfortunately isn't perfect and was designed with basically a single object to represent the entire browser of its time. This didn't scale well and unfortunately wrapping each and every object in Gecko is unreasonable. It is conceivable that someone might someday make a Glib-connect XPTCall layer or something like it that could proxy between XPCOM (or its replacement) and Glib. The main advantage of doing this is that no person would have to manually spend time writing bloaty wrappers for each and every imaginable Gecko object. | ||