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

[Dave Richards <drichard largo com>]

All-

    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.

Dave


On Tue, 2005-10-18 at 16:22 +0530, Kaushal Kumar wrote:
> 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.
>
> _______________________________________________
> Evolution-hackers mailing list
> Evolution-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers