Re: [Evolution-hackers] Update on the composer port

[Matthew Barnes <mbarnes redhat com>]

On Sun, 2012-09-02 at 00:16 +0200, Dan Vratil wrote:
> time to report on my progress in the composer port. I'd appreciate any 
> feedback and ideas.

Thanks for the progress update!

The class breakdown sounds good to me.  I'm all for having lots of small
classes with a well-defined purpose instead of some sprawling monolithic
monstrosity that no one can grok.


> EEditorSelection - represents current selection in the editor widget and
> 	provides API to modify formatting of the selection. I keep asking myself 
> 	if this could be merged to EEditorWidget, the main reason I haven't done
> 	it yet is that e_editor_widget_set_bold() does not describe correctly 	
> 	what the method does, unlike e_editor_selection_set_bold(). Also it makes
> 	the source files smaller. I hate long source files... :-) But if you would
> 	insist, I won't probably strictly object against merging it.

+1 - Haven't looked at the code yet, but I think I might prefer it stay
     split out.  GtkTreeView + GtkTreeSelection sets a precedent here.


> EEditorDialog* - implementations of all the dialogs. I decided to throw away
> 	the Glade file and single .c with implementation of all the dialogs 	
> 	because it  completely violates all principles of OOP and because I have 
> 	to provide my own implementation of most of the actions in the dialogs 
> 	anyway, so the single signals file would be huuuge and ugly.

+1 - Nowadays I think XML UI definitions are more trouble than they're
     worth.  Plus GtkBuilder still has problems handling single-letter
     type name prefixes (e.g. "E"), so using our own custom widgets in
     our own XML files requires frequent ugly hacks.  Not worth it.


> EColorChooserWidget - this is a "subclass" of GtkColorChooserWidget. 
> 	Unfortunately  API of the Gtk widget totally _SUCKS_, so it's more of a
> 	hack. It's point is to make the color chooser to accept color by single
> 	clicking it instead of double clicking. 

Perhaps the new GtkMenuButton in GTK+ 3.6 might help here?  Perhaps you
could subclass GtkMenuButton instead of GtkColorChooserWidget, but still
embed GtkColorChooserWidget in your subclass.


> EActionComboBox - I dragged this from /widgets/misc, because I need it in the
> 	Editor, but libeeditor can't link against libemiscwidgets (it links 
> 	against libeeditor).

Yeah, I'm toying with the idea of merging all these base libraries into
one.  libeutil + libemiscwidgets + libetimezonedialog + libetext +
libetable + libemenus + ... there's just way too many already.

Linking to all these shared libraries from layers higher up is a real
PITA and probably increases our startup time since each shared library
has to be loaded serially.


> Behavior of the editor is almost identical to GtkhtmlEditor, except for HTML 
> mode -> Plain text switching. GtkhtmlEditor is simply switching renderers on 
> top of a single DOM document, but we can't do this with WebKit. I looked how 
> others do it and ended up with a "Switching to plain text will lose all 
> formatting, OK?" dialog. When user confirms, all formatting is removed and 
> plain text version is inserted back to the editor. Switching from Plain text 
> to HTML does not alter formatting in any way (because there is no formatting 
> to alter :)

I'm sure we'll get some grumbling about that, but I can live with it.


> The "Undo"/"Redo" actions might be slightly broken/inconsistent with
> Gtkhtml as well, because I don't have access to the action stack of
> WebKit, and WebKit records only some actions. I'm using these actions I
> know that WebKit records to do most of the formatting/DOM manipulation,
> but on some places it's just not possible to get the right result this
> way.

That's a little more concerning.  Maybe we can work with the WebKit guys
to expose more of the undo framework?


> During the port I've run into at least one "unportable" thing - WebKit
> does not provide any means to change color of the underline of
> misspelled words, so I'll probably have to remove this feature (I don't
> see much use in it anyway).

I have no problem with that.  The underline color for misspelled words
should really be defined by themes anyway.


> Finally, Milan had some objections against the "EEditor" prefix, feel
> free to discuss a better alternative.

No strong opinion here.  I can live with EEditor.


> I'll write a blog post when the port is merged to master. I'd like to
> do the merge as soon as possible, because my time to continue working
> on it will be more and more limited during the semester, so the sooner
> you can test and report back the better. Feel free to start testing
> already (you can use the e- editor-test utility to test the editor
> itself). If you want to report bugs, please use evolution[composer] and
> evolution[webkit] whiteboards.

I plan to create gnome-3-6 branches after the 3.5.92 release later this
month.  We can merge immediately after to give as much testing time as
possible.

Thanks a ton for all your hard work on this.  GtkHtml was considered out
of date when I started at Red Hat way back in 2006, so abandoning it has
been a VERY long time coming!

Matt