Re: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)

[Kaushal Kumar <kakumar novell com>]

Hi,

Some of my thoughts on replacement of gtkhtml with gecko
(gtkmozembed/gtkmozedit).

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.

Cheers,
Kaushal

[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 <kakumar novell com>

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.