Re: PROPOSAL: Evolution for GNOME 2.6

[Marco Pesenti Gritti <marco gnome org>]

> Yeah, embedding the editor (Composer) is currently "Very Difficult If
> Not Impossible" according to
> http://www.mozilla.org/editor/editor-embedding.html
> Fortunately, that page was recently modified (end of October 2003) and
> it appears that the Mozilla folks are actively looking at addressing the
> issue. I doubt it will be done in the GNOME 2.6 timeframe, however. 

I agree that is not for 2.6 timeframe. (Probably trying to port yelp to
gecko would be more feasible).

Anyway it seem to be sort of working already. Probably some of the
features discussed in that document will not be necessary for evolution.
There are several tests using it in mozilla tree and
the windows activex control use it too.

I tried to add set_editable api to epiphany and it seem to work. If
someone is interested in trying it out I can put the trivial patch
somewhere.
A list of commands currently supported is available here:
http://lxr.mozilla.org/mozilla/source/editor/docs/Editor_Embedding_Guide.html
It should be possible to execute them just using current epiphany embed
api.

> I don't know enough about Mozilla/XUL/XBL to know how difficult/easy it
> would be to embed arbitrary Gtk+ widgets in mozilla.  Although, I'm sure
> it could be done with some <object>/plugin/bonobo hackery (yuck).

Yeah the only way that comes to my mind is plugins.

> It's long been on my "user-wishlist" to get rid of one or the other of
> GtkHTML2 or GtkHTML (or both) in favor of Gecko (well, kind of, I've
> always liked the GtkHTML2 code myself, but having 3 HTML libs in the
> platform is bordering on ridiculous).  Having mozilla in the
> desktop/developer platform creates a lot more duplication than just the
> HTML renderer, however.  Off the top of my head it means we have 2 of:
> 
>       * XSLT library (libxslt) -- not sure if this is in the platform or
>         not

Yeah it's in the platform. Though the public api is very small and
probably not very complete.

>       * "VFS layer" (gnome-vfs) -- 'necko' I believe it's called, it has
>         pluggable backends, though I'm not sure how comparable it really
>         is to gnome-vfs it does serve a similar function

Well they certainly overlap for some functionalities but they are not
quite the same. For example I dont think necko supports network
abstraction or mime types and for what I know vfs is not exactly viable
as network library (i.e. you couldnt base a browser on it).

>       * XML UI definition language (xul --> glade) -- "libgxul" might be
>         an interesting project (basically libglade over XUl, haven't
>         looked at XUL in a long time, don't know if it's even possible)

The way they works seem too different to me to make a libgxul possible.

I'd add at least XPCOM and i18n system (which isnt exactly a library but
...) to the list.

> Sadly, I don't see any of that duplication going away any time soon
> because Mozilla has a strong aversion to using outside code (whether
the
> merits of this approach to platform independence outweigh the costs is
> open for debate ;-)) and, despite being "highly modular," is organized
> in such a way as to make using the individual pieces outside of the
> framework difficult.

Yeah, I'm very often frustrated with mozilla cross-platformness too.
Though it's the best web rendering engine available. Reinventing it to
make the library stack cleaner would 1 not work 2 be a great waste of
resources that could be spent to solve more user visible problems.

I think exposing in the platform the part of the mozilla embedding api
that's useful for yelp/devhelp/evolution/epiphany, wrapped in
gtkmozembed like C api, is an acceptable approach.
Epiphany will probably ever need something more, though we are not
forced to expose this in the platform.

Marco