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 

        - 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.

Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be -

Evolution-hackers mailing list

Reply via email to