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 copypaste 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.
snip
---
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
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.
Interesting. I will try to take a look.
[ 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. ]
Good idea.
Thanks,
Paul
--
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
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.
snip
---
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] 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] 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
[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 this way.
That's probably
[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
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] 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
[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
[Evolution-hackers] WebKit port progress update
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
[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 div 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
