From a System Administrator perspective, I would be concerned about the following things:

- Performance of this change to remote DISPLAY Xservers (keystroke speed, scrolling speed).
- Performance on Xservers with no RENDER extension (still lots of those devices out here).
- Performance without XShm, shared memory because it's no longer on the system console/video card.
- Endian issues from Intel-->RISC, and the opposite as well when using remote DISPLAY.
    (there are some sections in the Beagle Best UI that don't display correctly on RISC devices).

My suggestion if appropriate would be to build a small composer window only, and let people test it on various hardware and network configurations.  I can test all of the above items here for you.  I would say that composing email is kind of an important thing in an email package and we all know that sometimes things come up when tested with diverse hardware.


On Tue, 2005-10-18 at 16:22 +0530, Kaushal Kumar wrote:

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
Evolution-hackers mailing list

Reply via email to