[Evolution-hackers] Home news from the Evo/WebKit Universe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, just a short note - thanks to Milan who has decied to dig into WebKit, embedding widgets into WebKit webview works again. I have thus thrown away most of the multi-webview code and I'm rewriting some code to render the email as a single HTML page. Welcome back the single-webview Evo. And it looks way much better then the multi-webview hybrid :) Unfortunately testing is now a bit more difficult because you must have WebKit compiled with the patch [1]. The patch is already reviewed and will be merged to next stable release (which will be unknown when). So that's all, just wanted to share some good news :) Bye, Dan [1] https://bug-63451-attachments.webkit.org/attachment.cgi?id=126053 (in case someone wanted to try it so bad) - -- dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPM6obAAoJEMWdYU9vSuNII48IAMsF8xLbSlSGwJSgWHphZsyK PnxH/sKkI1YKNBYSkexWbZE/2zEylTaj26nNEKTXwgUvZXsIK8P0HBYikJN0e0mq kLzrgki8ovlCh/JL/35FNdHYky2ye5j7PWs9AkAOmx/B4Ujx00tY6vo6PaOatLAM qeABr+EiQl39I5KEbsyPtUxHYP7w4IaTsoMu4ZYSAo2xBhWeNema4WI68696PFev KHXzI2crGBu94XSMUA+Cw1YuqbXY8616vqaqlz2+/vHdjPxDZuaSrp1EHxekwr4W dVSJGAZwT2gzr49wPEsEuPcMRzaivTdDRDGbc6G3wibkKz5xpNTDatQoi3GMuSE= =SLvR -END PGP SIGNATURE- ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Hot news from the Evo/WebKit Universe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subject: Home news from the Evo/WebKit Universe ...I'm pretty much sure I've typed "Hot"... - -- dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPM6qvAAoJEMWdYU9vSuNIrhIH/i7EYu6+AJ3DoLGlxLkMMnkS jm71ZC+Drm6779+uZgFui1Yaqas2xf8ZDj7RGUBLaVfNoHXIVmoPA2GaZk7WVFHZ nh6HXsEYacUeg8vAHqtgoE2MFaZ/gCm65XkZe160C5oG0SXwykgZP5GPnYHInn5q hQnqZMFYGy6c3aHeEVWqkidx+mL2GirsZG6JxcTxKvmsXC1rcgYcnsjpKkCZ0S3H MX65wmCDPt6J6cryOHBoJxZypX3mlMXyCO0hFkF1Ox75UPtv0zZE9ddHYL5kJvVs kC4hFGLvRddJmFz25KCKnWA4HZXpQUO40RT8HpKg4Yh1iB7lSENSjdILYIUpaps= =Eh8u -END PGP SIGNATURE- ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit branch is ready
On Wednesday 28 of March 2012 17:59:27 you wrote: > On Wed, Mar 28, 2012 at 4:13 PM, Daniel Vratil wrote: > > Hello everyone! > > > > WebKitGtk+ 1.8.0 with the important patch has been released last night, > > and so everything is in place now and I'm ready to break^W merge to > > master. The branch has been rebased two days ago, I will only bump the > > webkit dependency version later today. > > > > I hereby ask you guys for review and approval for the merge. > > This is great news. Im just so excited to try things out for 3.5.x. Do > you have webkit for composer too? Hi, only email reader is done so far, I will start hacking on composer now. I have quite a lot of time till 3.6 and hopefully the composer won't take as much time as the reader did, so if things go well, we could kill GtkHtml for good in 3.6 after all :) Dan > > -Srini. > > > I'd suggest creating 4 or 5 new commits directly in master instead of > > actual git merge to avoid polluting master history with nearly 200 > > commits of my furious development :) > > > > Cheers, > > > > Dan > > ___ > > evolution-hackers mailing list > > evolution-hackers@gnome.org > > To change your list options or unsubscribe, visit ... > > http://mail.gnome.org/mailman/listinfo/evolution-hackers -- dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] A better mail formatter
Hi, I've spent last few weeks re-working the email formatter and I think it's finally ready for landing to master. Milan will review it on Monday or so and if it's OK, I'll commit it early next week. I have already reworked it for the WebKit port, but the result was not good. There was only one class (EMFormat*) which was doing two completely separate actions - parsing and formatting and everything was stuffed in just a few .c files, making the code quite a mess. I have realized that the formatter could be made much more flexible and nicer by making proper object-oriented design. With Milan we have came up with quite a nice design. The first big step is to move everything to libemformat. Why have something here and something there. The parser and formatter were separated to their own classes EMailParser and EMailFormatter and the _actual_ parsing/formatting is done by extensions. Essentially there is a class for each mime type we support and they are derived from EExtension. This splitting makes the code much easier to read, navigate in and keep it in shape. As part of the work, I converted some plugins, namely audio-inline, itip- formatter, prefer-plain, tnef-attachment and vcard-inline, to modules. There is no API yet to extend the preferences dialog though, so for this some of them still install a little EPlugin-based library with the GUI. The main improvement here is that they react to changes in settings immediately, no need to restart Evo, some of them even cause the current view to refresh immediately. When a proper API for this is in place we can make on-demand loading etc. And why we have done this all? Because of text-highlight module. I've written less technical blog about it, so see for yourself what we already have and what I plan for near future. http://www.progdan.cz/2012/06/evolution-gets-a-new-e-mail-formatter/ Bye Dan dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit port of the composer
On Friday 01 of June 2012 11:47:31 Matthew Barnes wrote: > On Fri, 2012-06-01 at 16:49 +0200, Daniel Vratil wrote: > > I have nearly finished reworking the e-mail formatter (details in the > > other > > mail) and I want to slowly turn my attention to the composer. It will be a > > lot of work, but hopefully I'll make it for 3.6 (no, I WILL make it for > > 3.6!!!). > Awesome that you're starting in on that already! Next week or two will be mostly about fixing the bugs that I've postponed until the new formatter is landed. But I want to start shaping the composer in my head already :) > > 3.6 is pretty ambitious though. We can't be landing major features too > late in the development cycle and 3.6 is already a doozy. You need to > allow adequate time for testing and bug fixing before a stable release. > > 3.7.1 seems a more realistic target. I'd be no less thrilled to be rid > of GtkHtml by 3.8. I wanted to aviod shipping a hybrid. But if you say so... > > > If you have any special wish (I bet Andre will come with many feature > > requests from bugzilla :P ) you'd like to have in the new composer, > > please share them now. Regarding features, I want to make exact copy of > > GtkHTMLEditor and only fix the most annoying GtkHTML issues, all crazy > > ideas will be deferred for 3.8> > > :) > > Sounds pretty reasonable. > > My only request off the top of my head is to not subclass GtkWindow for > your simple/html editors like GtkhtmlEditor does. That was never my intention :) > That was a mistake on > my part because it precludes us from embedding the editor in an existing > window, and you'll likely want to do that later when you start working > on a Conversation View. ;) I probably missed something...? :) > I suggest GtkGrid as a base class. Yup :) > > Out of curiosity, what does WebKit/GTK+ use for spell checking? > Enchant? Will their APIs allow us to recreate the context menu with > spelling suggestions plus other editing actions? Yes, they use Enchant. The API [0] seem to be able to return only single word for autocorrect, but I guess we can fill in the missing functionality by working directly with Enchant? Dan [0] http://webkitgtk.org/reference/webkitgtk/stable/WebKitSpellChecker.html > > Matthew Barnes -- dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A better mail formatter
On Friday 01 of June 2012 17:29:59 Matthew Barnes wrote: > On Fri, 2012-06-01 at 19:10 +0200, Dan Vratil wrote: > > I have realized that the formatter could be made much more flexible and > > nicer by making proper object-oriented design. With Milan we have came up > > with quite a nice design. > > That sounds freaking awesome! > > > The first big step is to move everything to libemformat. Why have > > something > > here and something there. > > I vaguely recall EMFormatHTML had some mail-specific dependency that > kept it in the mail library, but maybe that's long since been solved. > > It totally makes sense to consolidate if that's indeed possible now. Haven't found any :) Btw I forgot to mention that I also renamed EMailAttachmentBar to EAttachmentBar and moved it to widgest/misc as I haven't found any real reason for it to be in mail. It's a widget, it does not really have any mail dependency and all other EAttachment* components are in widgets/misc already. > > > The parser and formatter were separated to their own classes EMailParser > > and EMailFormatter and the _actual_ parsing/formatting is done by > > extensions. Essentially there is a class for each mime type we support > > and they are derived from EExtension. > > I'm literally crossing an item off my own To-Do list now. Nice! \o/ > > > As part of the work, I converted some plugins, namely audio-inline, itip- > > formatter, prefer-plain, tnef-attachment and vcard-inline, to modules. > > There is no API yet to extend the preferences dialog though, so for this > > some of them still install a little EPlugin-based library with the GUI. > > That would be itip-formatter and prefer-plain, right? Exactly. > > Nowadays I'm not sure the Preferences dialog should even be extensible > at all. It's too tempting to just tack on options willy-nilly without > giving them sufficient thought. If something's important enough to show > up in the application preferences then it probably ought to live in the > core application. That's just my opinion. > > I'm inclined to suggest just add those plugin preferences directly. I'm for it doing right with this patch. If we promote itip-formatter and prefer-plain to be core parts, we can get rid of the EPlugin hack there. The other ({audio,vcard}-inline and tnef-attachment) will still have to install the .eplug XML in order to appear in the plugins dialog though. > > BTW, my branch and your branch will probably collide in itip-formatter, > but hopefully the conflicts are easy to resolve. Yeah, but it looks like it's the only place we actually met. :) I'm rebasing the patch on top of your changes right now and so far it went quite well. > > > And why we have done this all? Because of text-highlight module. I've > > written less technical blog about it, so see for yourself what we already > > have and what I plan for near future. > > > > http://www.progdan.cz/2012/06/evolution-gets-a-new-e-mail-formatter/ > > Neat! Does the text-highlight have to be chosen each time or is it > remembered somehow? Milan was suggesting that Evo should remember the chosen formatter, and I remember I was against it, but I can't recall for what reason :) But it's a matter of discussion because as said in the blog, this feature is not yet done. Dan > > > Matthew Barnes -- dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A better mail formatter
On Friday 01 of June 2012 19:10:05 Dan Vratil wrote: > Hi, > > I've spent last few weeks re-working the email formatter and I think it's > finally ready for landing to master. Milan will review it on Monday or so > and if it's OK, I'll commit it early next week. Hi, I just committed the new formatter to git master. If you find any issue or major divergence from the behavior of 3.4 formatter, please open a bug in. Please tag the bugs with "evolution[formatter]" so that it's easier for me to track the issues. I'll be now working on the bugs with which I've been waiting for this new formatter and of course fixing anything new that appears. Dan > > I have already reworked it for the WebKit port, but the result was not good. > There was only one class (EMFormat*) which was doing two completely > separate actions - parsing and formatting and everything was stuffed in > just a few .c files, making the code quite a mess. > > I have realized that the formatter could be made much more flexible and > nicer by making proper object-oriented design. With Milan we have came up > with quite a nice design. > > The first big step is to move everything to libemformat. Why have something > here and something there. > > The parser and formatter were separated to their own classes EMailParser and > EMailFormatter and the _actual_ parsing/formatting is done by extensions. > Essentially there is a class for each mime type we support and they are > derived from EExtension. > > This splitting makes the code much easier to read, navigate in and keep it > in shape. > > As part of the work, I converted some plugins, namely audio-inline, itip- > formatter, prefer-plain, tnef-attachment and vcard-inline, to modules. There > is no API yet to extend the preferences dialog though, so for this some of > them still install a little EPlugin-based library with the GUI. The main > improvement here is that they react to changes in settings immediately, no > need to restart Evo, some of them even cause the current view to refresh > immediately. When a proper API for this is in place we can make on-demand > loading etc. > > And why we have done this all? Because of text-highlight module. I've > written less technical blog about it, so see for yourself what we already > have and what I plan for near future. > > http://www.progdan.cz/2012/06/evolution-gets-a-new-e-mail-formatter/ > > Bye > > Dan > > > > dvra...@redhat.com | Evolution developer > GPG Key: 0xC59D614F6F4AE348 > Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 -- dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] text-highlight plugin and webkit-composer branch
Hi, just a notice about some news from my side: 1) I pushed the completed text-highlight plugin on Wednesday. This means, that in every plain-text part (be it text/plain, text/html or just some source code file), you can right click the part and you should see "Format as..." submenu where you can pick from various formattings (highlight utility is required). Note that you need to left-click on the part you want to highlight before opening the context menu. There is a known WebKit issue with focus on iframes and you need to give the iframe with content focus so that the context menu gets valid information about the underlaying iframe. 2) I published webkit-composer branch. The editor is in widgets/editor subdirectory. To test it, you only need to rebuild widgets/misc and widgets/editor. There is e-editor-test utility in the same folder if you want to play. So far it can only do basic formatting (the other buttons will probably crash it), but at least it works a bit! 3) This is actually not much of a good news for Evolution...sometime during the next two or three months (no date set yet) I will be switch teams within Red Hat and I'll go working on Qt & KDE stuff. It's not confirmed yet (but hopefully it will work out eventually), but I want to give you some heads up, so that's it not that sudden when it happens. I intend to still be around, making new bugs and breaking things, I'll just have less time to dedicate to the project. And that's pretty much it... Bye! Dan -- dvra...@redhat.com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Update on the composer port
Fellow Evolutionists, time to report on my progress in the composer port. I'd appreciate any feedback and ideas. Disclaimer: a long email, you have been warned. For diligent readers, reward at the end :) When I was starting the port, I essentially just looked on the GtkhtmlEditor sources and tried to clone as much as possible. What I ended up with is a set of classes located in /widgets/editor (libeeditor), which at the end are not really a clone of GtkhtmlEditor... EEditorWidget - WebKit subclass, provides API for configuring behavior of the editor 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. EEditor - a GtkGrid with toolbars and EEditorWidget. Can be subclassed to something like ESimpleEditor to be used elsewhere in Evo with limited set of features. 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. EEditorWindow - a GtkWindow which contains EEditor and simple API to pack widgets above or below the editor. It's used by the signature editor and composer and it's there so that I just don't have to copy-paste that much (and because it's the right thing to do ;-). 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. EImageChooserDialog - this is a cool GtkFileDialog subclass that displays preview of selected image next to the file list. The contact editor does it too, but it does not provide the dialog as a separate class. TODO: The contact editor could probably be ported to use this class EEmoticon* - GtkhtmlEditor used to call this GtkhtmlFace, which is a silly and confusing name. This is one of the very few parts that are almost exact clone of GtkhtmlEditor code. 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). I also tweaked some of the dialogs: for example the Find dialog now supports search wrapping (because WebKit supports it :), "Insert Link" dialog has a new "Remove Link" button and I also unified the buttons - all dialogs (except for the Link dialog) now have only "Close" button, because the changes are always applied immediately, so "OK" makes no sense there. This was slightly inconsistent across GtkhtmlEditor dialogs. I also ended up with my "own" implementation of spell-checking, which are located in e-utils. ESpellChecker - can list all dictionaries and can be used as "storage" for currently active dictionaries. Also implements WebKitSpellChecker interface, so it can be (and is) used as implementation of spell checking in EEditorWidget/WebKit. ESpellDictionary - a thin wrapper around EnchantDict which provides reference counting and nice names (en_US -> "English (American)"). You can either e_spell_dictionary_{learn,ignore}_word() for specific dictionary or e_spell_checker_{learn,ignore}_word() for all active dictionaries in the spell checker. The ESpellChecker. 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 :) 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 thi
Re: [Evolution-hackers] Update on the composer port
On Sunday 02 of September 2012 15:09:32 you wrote: > On Sun, 2012-09-02 at 00:16 +0200, Dan Vratil wrote: > > 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. > > Please excuse my ignorance, but how will plain text mode work in the > future? Will it still be possible to define item lists, indent blocks, > etc.? I must admit I forgot to test block styles in plain text mode. and as I can see now It does not work very well. That can most probably be fixed though, so lists, block indents etc will be possible in plain text mode as they are now with GtkhtmlEditor. The only difference is that you won't be able to compose a mail in HTML mode and then just switch to plain text whilst keeping all the formatting. You'd have to re-apply all the formatting again. (Theoretically, a filter could be written to convert HTML to plain text using the "email markup" - *for bold*, /for italics/, _for underline_, tab+* for list items etcbut it would still drop things like images (or it could convert them to ASCIIart :-D ) Dan -- dvra...@redhat.com | Associate Software Engineer / BaseOS / KDE, Qt GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Update on the composer port
On Tuesday 04 of September 2012 12:08:11 Matthew Barnes wrote: > On Sun, 2012-09-02 at 00:16 +0200, Dan Vratil wrote: > > 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. The problem is in the GtkColorChooserWidget itself. It's just a layout that wraps GtkColorSwatch, which is the actual color picker widget. The problem is that GtkColorSwatch is not a public widget (wh?) and only emits "activate" on color when you double-click it. So I have to hack in, override the widget's press-event and manually emit "activate" on the swatch on single click. Since we are aiming for 3.8 with this I hope to make Gtk devs see how much stupid this is and propose/provide something better. Until then we will live with the hack :) > > > 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. Unless your filesystem is a real mess, I'm not sure that the startup time will increase significantly. But I agree that the amount of libraries is getting a bit out of hand. My humble proposal would be something like libeaddressbook, libecalendar, libemail and libecommon (everything used by more then one module). It would probably require mangling of the classesand it's very-OT for the scope of this mail :) > > > 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? We'll see if they will be willing to work on it. I'm afraid most of their resources is dedicated to WebKit2 API. > > > 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. That would be great. Hopefully I'll be able to port the signatures until then. Cheers, Dan -- dvra...@redhat.com | Associate Software Engineer / BaseOS / KDE, Qt GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH] Bug #684175 – Check for corrupt addressbook
On Wednesday 19 of September 2012 11:20:26 Paul Menzel wrote: On Wednesday 19 of September 2012 11:20:26 Paul Menzel wrote: > For whatever reasons, addressbooks can be corrupt. Clicking on such an > entry in the Contacts overview crashes Evolution with a segmentation > fault. In the overview the first line of the excerpt is empty. > > Therefore the return values have to be checked, which is also good > programming practice. > --- > What should be done in `e_destination_set_contact()` in the error case? > A warning to the user would be nice telling her/him to edit the > addressbook or Evolution should fix up the addressbook entry itself but > also notifying the user. > > addressbook/libebook/e-destination.c |9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/addressbook/libebook/e-destination.c > b/addressbook/libebook/e-destination.c index 96582d1..9808fe8 100644 > --- a/addressbook/libebook/e-destination.c > +++ b/addressbook/libebook/e-destination.c > @@ -463,8 +463,13 @@ e_destination_set_contact (EDestination *dest, > > raw = > e_vcard_attribute_get_value (attr->data); > addr = > camel_internet_address_new (); > - camel_address_unformat > (CAMEL_ADDRESS (addr), raw); > - camel_internet_address_get > (addr, 0, &name, &email); > + if (camel_address_unformat > (CAMEL_ADDRESS (addr), raw) <= 0) { > + /* Report an error that > contact is corrupt */ > + } > + > + if (!camel_internet_address_get > (addr, 0, &name, &email)) { > + /* Report an error > corrupt */ > + } > > e_destination_set_name (s_dest, > name); > e_destination_set_email > (s_dest, email); In general I agree with your approach, but I don't know whether it makes sense to report error to user here (can there be other reasons for camel_internet_address_get() to fail other then addressbook corruption?). I'd simply suggest something like: if (camel_address_unformat (CAMEL_ADDRESS (addr), raw) > 0) { if (camel_internet_address_get (addr, 0, &name, &email)) { e_destination_set_name (s_dest, name); e_destination_set_email (s_dest, email); } } I think the _actual_ problem is, that name and email variables are not initialized before being passed to camel_internet_address_get(). The crash comes from g_strdup() in e_destination_set_{name,email}() which tries to duplicate an invalid memory. According to docs, g_strdup(NULL) returns NULL, so that would prevent any crash in the first place. But as you said above, checking return value is a good practice, so combining these two would be valid solution. [ Off-topic: could we consider enforcing stricter compiler warnings? Getting "possible use of uninitialized value" and similar warnings would for prevent us from introducing crashes like this one. ] Cheers, Dan -- dvra...@redhat.com | Associate Software Engineer / BaseOS / KDE, Qt GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH] Bug #684175 – Check for corrupt addressbook
On Wednesday 19 of September 2012 22:11:28 Paul Menzel wrote: > Am Mittwoch, den 19.09.2012, 12:29 +0200 schrieb Dan Vratil: > > On Wednesday 19 of September 2012 11:20:26 Paul Menzel wrote: > > > On Wednesday 19 of September 2012 11:20:26 Paul Menzel wrote: > ^^ > > Is putting the line introducing the quote twice a bug in a KMail > version? No, that's my incapability to correctly copy&paste plain text :) > > > > For whatever reasons, addressbooks can be corrupt. Clicking on such an > > > entry in the Contacts overview crashes Evolution with a segmentation > > > fault. In the overview the first line of the excerpt is empty. > > > > > > Therefore the return values have to be checked, which is also good > > > programming practice. > > > > > > > > > --- > > > What should be done in `e_destination_set_contact()` in the error case? > > > A warning to the user would be nice telling her/him to edit the > > > addressbook or Evolution should fix up the addressbook entry itself but > > > also notifying the user. > > > > > > addressbook/libebook/e-destination.c |9 +++-- > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > diff --git a/addressbook/libebook/e-destination.c > > > b/addressbook/libebook/e-destination.c index 96582d1..9808fe8 100644 > > > --- a/addressbook/libebook/e-destination.c > > > +++ b/addressbook/libebook/e-destination.c > > > @@ -463,8 +463,13 @@ e_destination_set_contact (EDestination *dest, > > > > > > raw = > > > e_vcard_attribute_get_value (attr->data); > > > addr = > > > camel_internet_address_new (); > > > > > > - camel_address_unformat > > > (CAMEL_ADDRESS (addr), raw); > > > - camel_internet_address_get > > > (addr, 0, &name, &email); > > > + if (camel_address_unformat > > > (CAMEL_ADDRESS (addr), raw) <= 0) { > > > + /* Report an error that > > > contact is corrupt */ > > > + } > > > + > > > + if (!camel_internet_address_get > > > (addr, 0, &name, &email)) { > > > + /* Report an error > > > corrupt */ > > > + } > > > > > > e_destination_set_name (s_dest, > > > name); > > > e_destination_set_email > > > (s_dest, email); > > > > In general I agree with your approach, but I don't know whether it makes > > sense to report error to user here (can there be other reasons for > > camel_internet_address_get() to fail other then addressbook corruption?). > > Unfortunately I do not know. > > > I'd simply suggest something like: > > > > if (camel_address_unformat (CAMEL_ADDRESS (addr), raw) > 0) { > > > > if (camel_internet_address_get (addr, 0, &name, &email)) { > > > > e_destination_set_name (s_dest, name); > > e_destination_set_email (s_dest, email); > > > > } > > > > } > > Still the user should be warned somehow and told how to fix this. Hmm, you could probably update e_destination_set_contact() to return FALSE upon failure, then check for the return value in EABContactFormatter. The async operation running in formatter can set a GError value and terminate. The GError can be picked by EABContactDisplay which can finally display the error to user (using EAlertSink). Thinking about this I remembered that Milan told me some time ago that it would be nice to make the new formatters and parsers to support GErrors (he was talking about the mail formatter, but the addressbook is using the same concept). This would give us some nice error reporting. So far when the formatter fails, you either get an empty preview pane or "Failed to load part blahblahblah" message. Doing this in the addressbook formatter might be a nice "research" on how it should look and work :-) Cheers, Dan > > > I think the _actual_ problem is, that name and email variables are not > > initialized before being passed to camel_internet_address_get(). The crash > &g
[Evolution-hackers] WebKit port progress report
Hi folks, in last two weeks I've been continuing Matthew's work on WebKit branch and finally there are some results worth sharing. And one big bad news. The good news first: Matt has already ported EWebView and the stuff around, EABContactDisplay and ECalComponentPreview were already ported as well, so I at least took some care of the HTML code: EABContactDisplay The content of the preview is split to three of four blocks. In master the blocks are in a table layout, so that there must be one code for horizontal and one for vertical layout. I converted these blocks to floating elements, so that when in vertical preview, when the blocks won't fit next to each other, they are automatically displayed below each other. Note, that when you make the vertical preview wide enough, the "Work" and "Personal" blocks fit side by side, which looks very good I think. This allowed me to reduce the code of HTML-generator a lot. I also moved some styles to a CSS file (/usr/share/evolution/% ver/theme/webview.css) - mainly colors and font-sizes of the headers, titles etc. Finally, instead of re-rendering the entire HTML code when a contact list is collapsed/expanded, I implemented the functionality in JavaScript, which makes it faster and the code is much cleaner. ECalComponentPreview There was nothing much to do here, I just applied the stylesheet from webview.css. The look is now consistent with look of contacts preview. EMFormatHTML This gets ugly. WebKit does not provide any means to set content of a resource (image, frame...) other then by settings URL of the resource to "data:base64,base64_encoded_data". Pretty ugly. What's worse, there's absolutely no way how to do this asynchronously (well, there is - I'll get to it). So now the primary formatting (headers, "main" content) is done asynchronously the old way (create HTML -> e_web_view_load_string) and any other resource, when requested, is loaded by the method describe above, but asynchronously (I have never run into a UI-freeze while testing, but I can imagine that parsing some crazy 5MB large HTML email and encoding it to base64 can take some time...). For now, the preview can display plain text mails, HTML mails and can even load multipart/related subparts. The collapsible headers were ported to JavaScript to safe some code in EMFormatHTML. The only chance how to make EMFormatHTML completely asynchronous is to use unstable libsoup API and create our own content handler which when a request is send would fetch the mail part, decode it and send it as a response. The trouble is, that I haven't found (yet!) any way, how to pass a CamelMimeMessage to the parser (which is instantiated for each new request), because it is nontransparent to the request sender. Composer Until Composer is ported, I took EWebView from master, renamed it to EWebViewGtkHTML and updated Composer to use it instead of EWebView. Thanks to this, I can now write this email from the webkit-Evo :) Future plan is to take GtkHTMLEditor API, rip off it's guts and put in WebKit code. WebKitGtk bug (that's the bad news) There is a big ugly bug in WebkitGtk (see https://bugs.webkit.org/show_bug.cgi?id=63451 ). In short, WebKit does not render embedded GtkWidgets, so you can't see the attachment bar, inlined-image button etc. Luckily, there is a WebKit developer sitting in the cubicle next to mine whom I keep annoying about the bug (I've been probably annoying him so much that he rather went on vacation, but he should be back next week, so I'll start bugging him again :) ). What we already know, it won't be easy fixing and will take some time. Until a WebKit with the fix is released, the WebKit port is more or less useless for production. I think I can have Evo ported before 3.2, but I doubt WebKit will be fixed soon enough. So, that's the current standing. Until the bug is fixed, I have enough time to start digging into libsoup and make mail rendering completely asynchronous (which will probably take me some time). That's all for now :) Bye Dan -- - Dan Vratil dvra...@redhat.com +420 732 326 870 d...@jabber.cz ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] WebKit port progress update
looking there. I'm leaving now and I should be back on 5th or 6th September. I won't be able to check my email, so please be patient, I'll reply to all your comments as soon as I get back. Cheers - Dan -- Dan Vratil dvra...@redhat.com ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers