[Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)
- From: Philip Van Hoof <spam pvanhoof be>
- To: Evolution Hackers <evolution-hackers gnome org>
- Subject: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)
- Date: Sun, 16 Oct 2005 14:20:55 +0200
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]