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 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers