Some of my thoughts on replacement of gtkhtml with gecko

The basic set of features which would be needed in a gtkhtml replacement
are enumerated below:-

- Accessibility support
- RTL support
- Support for editing html objects like frames, iframes, etc.
- Support for emacs keybindings.
- Support for preview and print.
- Support for html embedded objects.
- Support for cut/copy-paste, drag-n-drop.
- Support for images and animations.
- Support for undo-redo.
- Support for IM.
- Text justification
- Find/Replace
- Dictionary interface
- Link handling
- Sub-parts of evolution like calender, tasks, addressbook interact with
gtkhtml for their stream display. 

Some of the above, as I understand, can be implemented via the command
manager of the gecko editor, whereas, others might need little more
work, which is not a problem. 

What is more important is implementing all the requirements finally, and
for now, determining if gecko editor provides a platform for achieving
it, or not.

As pointed out on irc yesterday, gtkhtml is buggy. But then, which
module is not? That may not be a reason good enough for it's
replacement, unless we have met a dead end and the open bugs are not
fixable [1]. 

However, if mozilla technology promises a better user experience at face
value, then it is worth the migration.

GtkHTML does not support CSS, DOM as yet. This could be because it was
designed to be a lightweight mail editor/renderer, in the first place.
However, if mails use CSS more now, it would be useful to add it.

To do this, we could either simply add it's support; or, we could try
using gtkmozembed for rendering (on similar lines of epiphany). The
editing part could still be left to gtkhtml (or maybe a scaled down
version of gtkhtml). 

I would like to re-affirm that I too favor switching to gtkmoz*, if we
could create a plan/design, to fill-up for the existing gtkhtml
features, along with that of adding new ones. Since I have not much
expertise in mozilla-related stuff, someone else could do this analysis
and I could help by reviewing it. Philip's initial investigation on the
replacement plan is a very good start (thanks for the wiki page on the
same). I admire and appreciate Rob's gtkmozedit work. I would be glad to
pitch-in all help possible, from my side.


[1]: I would appreciate if someone could send me a list of those gtkhtml
bugs which he/she considers to be critical that it hampers their work.
Kaushal Kumar <[EMAIL PROTECTED]>

On Sun, 2005-10-16 at 14:20 +0200, Philip Van Hoof wrote:
> Using my latest patch it's assured that the EMsgComposer struct members
> are no longer used outside the e-msg-composer.c file. Therefore it's
> safe to re-implement everything in the file.
> However. Not everything should be reimplemented. Some routines are not
> dependent on the editor component:
>       - All the methods that are related to headers
>       - The "mailto:"; parser and handlers
>       - Attachment handling
>       - GObject creation and boilerplate code
> Other parts are dependent on the editor component or visa versa. Parts 
> like:
>       - Message body handling (full replacement)
>       - Inline image handling (partial replacement)
>       - PGP handling (partial replacement)
>       - MIME handling (full replacement)
>       - Signature handling (partial replacement)
> It's untrue that there's no more maintenance for the HTML editor
> component if we'd switch to GtkMozEdit. However, there's a developer 
> (Robert Staudinger) doing it at this moment. And it's far less code
> to maintain (since most of the code is GtkMozEmbed and, of course,
> Gecko). There's however a few issues and things to add:
>       - You can only start using the GtkMozEdit (and GtkMozEmbed)
>         widget after realizing it is completed. This does take a
>         certain amount of time (mainly the firs time) and is difficult
>         to detect in the code (it's a signal). Some parts of evolution
>         perform methods on the newly created EMsgComposer instance
>         right after it got created. This would be to early (since the
>         GtkMozEmbed widget needs to be realized first).
>         This problem is deeply embedded in GtkMozEmbed (perhaps even
>         deeper, in Gecko). So it's not something that can be easily
>         fixed in GtkMozEdit.
>       - GtkMozEdit doesn't yet support the exact same amount of
>         "commands" as the GtkHTML component does. A lot of the 
>         "commands" need to be reimplemented.
>       - GtkMozEdit, however, does support DOM. Which will become
>         very useful (using DOM you can access the HTML nodes
>         individually and stuff like that).
> Unlike GtkHTML, the GtkMozEdit doesn't have "Bold", "Italic" etcetera
> buttons. So a  new widget should probably be created that adds this to
> GtkMozEdit (this is trivial).
> GtkMozEdit by default uses the default theme of Mozilla (for the
> scrollbar, fonts and in-the-document embedded controls). I haven't
> investigated how difficult it would be to change this. I'm guessing this
> is not very difficult.

Evolution-hackers mailing list

Reply via email to