21 Apr 2004
(updated 21 Apr 2004 at 19:09 UTC) »
I hope you will reconsider the backend
switch. Could you explain, in detail, what are the issues with
gstreamer? Bug numbers, criticisms of the framework design, blames
on the maintainers to not deal with your requests... everything
would be useful to identify the problem and try to solve it in a
reasonable timeframe. I'm convinced a bit more communication would
hugely improve the situation.
with mozilla SDK continues. It's taking a lot of my time but I think it's necessary, it's not my favourite hack but someone must do it. So, since this has been the main topic of this blog lately I'm in debt of an explanation to my 3 readers.
Gtkmozembed is a nice, simple widget that allows to embed mozilla renderer in GNOME applications. To be able to adopt it 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 use
and 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
- 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 technologies.
Here are some of the things I'm doing and plan to do to improve the situation:
- Make gtkmozembed a GRE
client. libgtkmozembed.so 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 + command handler api wrapped in gtkmozembed could allow to acces most editing functionalities with a gobject api.
I opened bug 140713 about this. Feel free to add notes there if you are interested. It's the first of the plan tracking bugs (man, I'm slow), I'm going to post one about gnome print integration ASAP.