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



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.

-- 
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
http://www.pvanhoof.be - http://www.x-tend.be




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]