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 <[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 Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
