After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 140713 - [Plan] Improve gtkmozembed to be more friendly to GNOME
[Plan] Improve gtkmozembed to be more friendly to GNOME
Product: epiphany
Classification: Core
Component: [obsolete] Backend:Mozilla
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Reported: 2004-04-21 12:29 UTC by Marco Pesenti Gritti
Modified: 2009-01-22 00:20 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Marco Pesenti Gritti 2004-04-21 12:29:24 UTC
To be able to adopt gtkmozembed more widely in GNOME applications (see devhelp,
yelp, evolution at least) we need to solve some issues:
1) DISTRIBUTION. We need better modularization. Atm you need to install the
whole mozilla browser to be able to use the widget. It would be cool to be able
to have mozilla-gre package with the base libraries that GNOME applications
could useand mozilla-browser, firefox packages dependent on it.

2) STARTUP. To start up an application using the widget now you need to create a
wrapper script to setup LD_LIBRARY_PATH to point to $prefix/lib/mozilla-$version.
Mozilla libraries are installed in a versioned subdirectory because they are not
api stable. This is probably the bigger cause of bug reports: the result of
running epiphany with a different version of mozilla than it was compiled are
obscure undefined references.

3) TOOLKITS MIX. Gtkmozembed api lack some basic functionalities. It's possible
to write XPCOM code to use mozilla interfaces directly, but that's somewhat ugly
code wise and anyway require to learn about XPCOM. For basic functionalities it
would be desiderable to depend only on the gobject api.

4) API. Mozilla public apis are beings stabilized but they are still somewhat
bit rotten and incomplete. I think what they really need is api users bugging
them to fix this situation (and helping obviously)

5) COMMUNICATION. There is basically no communication between the two
communities. This need to be solved ASAP, we de facto depend one on the other

Here are some of the things I'm doing and plan to do to improve the situation:
- Make gtkmozembed a GRE client. will be versioned and
installed in system lib path so that it can be parallel installed. (This
solves 1 and 2)
- Fix problems with mozilla SDK. In particular we have finally an embed string
api (string api changes has been the worst mainteinance hell for epiphany and
galeon so far) but there are some mozilla interfaces that doesnt "support" them yet
- Work with mozilla developers to add missing apis instead of just using private
- Port gnome applications to use gtkmozembed. Mikael ported devhelp already and
I need to convince shaunm to let me port yelp :)
- Add api to gtkmozembed for basic functionality. Find, print and zoom come to
my mind. We need a solution for preferences too (fonts for example). We could
add simple get/set api but ... it would be so much more useful to bridge gconf
and nsIPref :) Mozilla has a command handler api where you can use strings like
"cmd_cut" to execute actions (and get notified about their state). The editor is
heavily based on them: probably a set_edit_mode and a command handler could make
most editing functionalities available.
Comment 1 Marco Pesenti Gritti 2004-04-21 12:32:25 UTC
Plan bugs are used to track the work on next version major changes. You are
welcome to add requests, design notes, to ask clarifications, to offer to help
with it.
Comment 2 Christian Persch 2004-10-13 10:52:29 UTC
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Comment 3 Xan Lopez 2009-01-22 00:20:34 UTC
OBSOLETE now that we don't have a mozilla backend anymore.