Created attachment 150967 [details] [review]
Evolution MAPI patch

This should get the folder list. The iter stamp gets out of sync in few cases but that is expected. Those warnings are good. No harm.

It seemed to work for me even without the patch, I've no idea why. I saw all the hierarchy like in the mailer, which is probably not also the best, as choosing other than calendar/memo/task/contact folder in respective dialogs doesn't make much sense. Bharath, those warnings you are mentioning, are they some runtime warnings? If so, and they are expected, and you can avoid them, then please avoid them. The less evo will have on its console the better. (I kept one warning in one bug, but it was just for cases where the input were some semi-random binary data instead of utf8 string, which was expected. And I think it's slightly different from this case.)

Please think of checking the folder type and take care of runtime warnings. Thanks.

(In reply to comment #2)
> It seemed to work for me even without the patch, I've no idea why. 

It's due to gtk version. I have gtk 2.16 in one of my machine where hierarchy works fine. But if i upgrade to gtk 2.18 or master, i don't see hierarchy.

Thanks Milan for the quick review.

(In reply to comment #3)
> (In reply to comment #2)
> > It seemed to work for me even without the patch, I've no idea why. 
> 
> It's due to gtk version. I have gtk 2.16 in one of my machine where hierarchy
> works fine. But if i upgrade to gtk 2.18 or master, i don't see hierarchy.

Yup that's right. Well I don't know how the gtk version upgrade made any difference at all, I found a lot of flaw in the existing code itself.

First the fid is 0 for the main root node. So we shouldn't check for that. Then for traversing through the list of nodes, we cut it off on a gtk_tree_model_iter_next. So we get a critical warning once we reach the end of nodes in a particular level. So that also seems fine.

It works neat now for any gtk version and so this patch seems fine.

And yes since we use the same piece of code for all the components it does show up all the folders. Maybe we could just disable the mailer folders as they aren't needed. Probably have a check like,

if ( folder->container_class == MAPI_FOLDER_TYPE_MAIL)
     return;

That should filter out all the mail folders.

Oh, newer gtk+, I wouldn't expect it, but right, on 2.18 it doesn't work.

Runtime warnings: they should never happen, if they do, then something goes wrong. Change prototype of check_node to have the last parameter as
GtkTreeIter iter, not *iter, and change the rest as appropriate. Then there will be no runtime warning like before. Guess why :)

Show relevant folder types: exchange_mapi_create has EConfigHookItemFactoryData, which you cast to EABConfigTargetSource, but it's not correct for calendars, as calendars are using e-cal-config.h:ECalConfigTargetSource , which has a member source_type, with which you can recognize what source types to show. There is a little trick though, if one can create calendar source as a subfolder, then you should add the path from it to root too.

The easiest might be to duplicate exchange_mapi_create, one for calendar, one for addressbook. That it is working now is just a coincidence of structures content.

Since this bug is triggered by an upgraded gtk, it is likely that 0.28.x also suffers from this, correct?  Looking at the source code of 0.28.3 this patch seems to apply at least...

Please add to your fix also this chunk, as without that one can crash evo pretty easily by running it in Contacts and choose New Address book and pick the MAPI account, when the camel notification is doing its initial job. Thanks.

index 7ae454d..801e464 100644
--- a/src/libexchangemapi/exchange-mapi-connection.c
+++ b/src/libexchangemapi/exchange-mapi-connection.c
@@ -3159,7 +3159,9 @@ exchange_mapi_events_init ()
 {
        enum MAPISTATUS retval;
 
+       LOCK();
        retval = RegisterNotification(0);
+       UNLOCK();
 
        return (retval == MAPI_E_SUCCESS);
 }

Created attachment 158530 [details] [review]
ema patch

for evolution-mapi;

I thought of something like this. it includes couple things:
a) filling the folder list, only with the folders which are supporting
   the given source type
b) select the actual folder in the list
c) do not recreate ESourceGroups when some is available (I didn't find a bug
   report for that, so used this one)

Created commit c2f0a0d in ema master (0.31.1+)
Created commit 788f6e6 in ema gnome-2-30 (0.30.1+)

[ d) Comment #7 is obsolete for master, but was missing for gnome-2-30. ]