GNOME Bugzilla – Bug 201167
Complete implementation of category syncing
Last modified: 2013-09-13 12:31:13 UTC
The categories need to be pushed to/from the palm. Need to check how outlook handles this for items in multiple categories.
*** bug 201307 has been marked as a duplicate of this bug. ***
(getting rid of duplicate milestone name)
I apologize for the spam; re-setting all target milestones to 'future' in preparation for evolution 1.0. If you have any questions, please feel free to write louie@ximian.com.
*** bug 215510 has been marked as a duplicate of this bug. ***
*** bug 215927 has been marked as a duplicate of this bug. ***
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be moving a large number of bugs around in the bugzilla. You can just search on 'body contains' 'Because of the decision to remap' and mark all as read. Please direct all questions about this change to evolution@ximian.com, not the bug. Luis
*** bug 218498 has been marked as a duplicate of this bug. ***
*** bug 220100 has been marked as a duplicate of this bug. ***
http://www.palm.com/support/helpnotes/3rdparty/pocketmirror/cathelp.html Has some information on how Outlook deals with this.
*** bug 220362 has been marked as a duplicate of this bug. ***
*** bug 217153 has been marked as a duplicate of this bug. ***
*** bug 227219 has been marked as a duplicate of this bug. ***
*** bug 227576 has been marked as a duplicate of this bug. ***
*** bug 226078 has been marked as a duplicate of this bug. ***
*** bug 229128 has been marked as a duplicate of this bug. ***
*** bug 229558 has been marked as a duplicate of this bug. ***
*** bug 222227 has been marked as a duplicate of this bug. ***
*** bug 233438 has been marked as a duplicate of this bug. ***
Perhaps I can shed some clarity on this issue: For multiple categories, I have Pocket Mirror set up so it will only sync one category (probably the first in the list, from left to right). That would be a "no surprise" method for implementing this. I'm not sure if there's a way to vote for a priority for bugs to be squashed ala mozilla, but this gets my vote. I can't use Evolution without this functionality.
*** bug 234917 has been marked as a duplicate of this bug. ***
As of May 1, 2003 this bug has been filed 16 times that I can find. Is there anything we can do that might help you fix this, JP? This bug seems to be a problem for a lot of people.
*** bug 246880 has been marked as a duplicate of this bug. ***
Happy Birthday, bug 201167! Three years! As a birthday present, maybe you'll get your milestone set to something less depressing than "Future." How about 2.1?
Perhaps with Palm OS 6 this won't be much of an issue anymore since the Palm will support multiple catagories. Sure would be nice to have it on earlier Palm devices, though.
This is one of the most requested features in Evolution. Targeting tentatively for 2.1.0
is anything going on with this bug? It's a major feature lack that even though evolution has categories for syncing, they don't work with Palm's categories. I didn't notice anything about it in the 2.1.0 changelog
*** bug 266939 has been marked as a duplicate of this bug. ***
Sigh. Still not done.
Created attachment 47472 [details] [review] Patch for category syncing with todo-conduit.c
The patch above (sorry, forgot to put comments with it) mostly fixes the category syncing problem. Below is the e-mail I sent to the evolution-hackers mailing list to explain the two bugs that are left, in hopes someone can help fix me fix them. <e-mail> For quite a while, I've really needed the categories in the Tasks list to sync between my PalmOS PDA and Evolution. I finally spent some time getting it *mostly* working. Attached is the patch. I'm looking for comments on how it works and some help to get it completely working. It's 95% of the way there. The main problems: when using e_categories_add(), I can't get the categories to show up in the task-editor page or in the search bar until the Evolution client is restarted (data server need not be). The search bar shouldn't be too hard (I think), but I couldn't figure out why the task-editor page wouldn't show the new categories. Here's how it basically works: - Copy from pilot - done in the function add_record - If the category from the PDA doesn't exist in the eds, I add it using e_categories_add() - I set the category of that task to just the category from the PDA - Problems: - UI doesn't see categories addition until restart of evolution - if a syncrhonize is done, it's *possible* to lose categories. I tried to remedy this by using e_cal_component_get_categories_list, but it wasn't working properly and memory was getting messed up (even if I didn't free anything). Unknown as to why. - Copy to pilot - mainly uses local_record_from_comp - dlp_ReadRecordById doesn't work in this case - don't know why, but it doesn't - We do have the ToDoAppInfo, which holds the CategoryAppInfo - if 1 of the categories from Evolution's Tasks matches (string comparison) a category from the PDA, set the category to that index - if we find no matches between Evolution's categories and the PDA's, then see if there's an empty space in the category list. A space is empty if the strlen() of the name is 0. If space is empty, copy the first 15 characters of Evolution's category into the PDA category space and set the ID to be a PC-added category (starts at 128 according to the API). - if no match is found, but no space is empty, then the category is set to 0, which is the Unfiled category (this is how the PalmOS DB seems to work) - Since we're modifying the ToDoAppInfo struct, we need to write this back to the PalmOS. This is done in post_sync() using dlp_WriteAppBlock. - Synchronize - this is a combination of the two. Gnome-Pilot seems to take care of whether to call add_record or replace_record or delete_record where appropriate. - I have not changed compare or match - they seem to be working just fine. A small change outside of categories: Priorites 2 and 3 are "normal" priorities. Normal should be the most common priority, and since we don't have a 1-to-1 matching between priority types, I think this makes sense. (At least, I was wondering why I had so many "High" priorities - I'd rather switch to a 5-layer priority schedule, but I know Exchange uses the same as Evolution's). I'm looking for help on how to solve the problems above. I'm also looking for comments on what people think of the category matching/syncrhonizing. An improvement would to have specific Evolution categories designated as "Pilot" categories, assuming that pilot support was built-in. Maybe an EPlugin would be good for this. This is probably beyond the time I have now, though.
Will this be able to be backported to the 1.4 series?
Created attachment 47490 [details] [review] Evolution 1.4.6 cateogry patch Here's a patch that *should* work for evolution 1.4.6. I tested it out a little, but not too much (I'm having conflicts between the 1.4 and 2.3 series). Let me know how it works for you.
The 1.4.6 patch works, and works well. Thank you very much! Only issue I've found is that changing the category in Evolution doesn't propagate to the Palm. Also had a little issue with not all categories making it from the Palm to Evolution on initial sync, but that seemed to clear up with no noticable reason why it did that. Thanks again! You've made my year!
Glad it mostly worked. The main problem could be due to you already having 15 categories on your Palm. 15 is the limit (PalmOS limitation), and so we can't add anymore after that. If you have the output when it screws up, post it here. I can take a look at it, as the 2.3.1 version probably has that problem as well. There is one small problem with it that will cause a crash - I'll add a patch shortly (just checking to see if if a struct is NULL before accessing a member of the struct). I'll create a patch against a few versions for those wanting to use it - mainly the 1.4.6 and 2.3.x series.
Created attachment 47939 [details] [review] Updated patch for category syncing with todo-conduit This is an update of category syncing for the 2.x.y series of todo-conduit.c. This fixes a possible dereferencing of a NULL g_slist object.
Created attachment 47940 [details] [review] Updated patch for Evo 1.4.6 for category syncing with todo-conduit As with the update for the 2.x.y patch, this fixes a possible dereferencing of a NULL pointer.
Mubeen, please verify if this patch works with 2.3.x. If so, we must thank Nathan for working on this.
Krish: I will verify it.
Created attachment 53773 [details] [review] Updated patch against CVS - Oct 22, 2005 Here's an updated patch against current CVS HEAD. I've tested it, and it still works. I'd like to get this patch in before 2.5.1 if possible. Without it, I have to patch the latest release (or CVS) before syncing with my Tasks list, which I seem to be using more and more lately. Thanks.
*** Bug 320536 has been marked as a duplicate of this bug. ***
in CVS head now. Nathan: Thanks for your patch.
Thanks for committing it. As I'm going back through the entire bug, I realized that categories for the addressbook and calendar need to be synced as well (memos category syncing was built-in from the start, since I wrote that component). I should have patches within a few weeks for the calendar and addressbook category syncing. I'd like some help from people running pre-PalmOS 5.2. I have a Tungsten E, and while the "classic" databases are used to sync with, I'd like some help testing using the older systems.
I have Handspring Visor (old model), will it be of any use? If so, what kinda testing you want to do?
I have a Palm Vx, and was a bit overly optimistic about my expectations of evo syncing before I got it a week or so ago. I will be glad to help with any testing - I am currently running Ubuntu Breezy, but am willing to upgrade to Dapper or compile from CVS if it would help in the development of the Palm support.
Currently, this patch is in CVS. If you get Evolution, GtkHTML, and libsoup from CVS, you can test the Tasks. I'd be happy to have people testing it. I don't know if distributions are going to be including the patches in their own releases. The type of testing I'd like to see is basically try to change categories in multiple ways (both on the Palm device and Evolution) and see if the syncing still works. First, try seeing if the categories can be copied from the device to Evolution, and then vice versa (Copy to Pilot, Copy from Pilot instead of Synchronize). The next test would be to use Syncrhonize, but first changing categories only on the PDA and then only on Evolution. The next test I typically run is to change modify the categories of a few entries on the PDA, and then on different entries in Evolution, do the same. After that, I try to see what happens if I change the category on the same entry both on the PDA and Evolution. The result of that test should be duplicate copies of the tasks, but different categories. Another test to run is to see what happens if there are multiple cateogires in Evolution. The first one in the categories list should be the one chosen to be use on the PDA. The user has no real control over that, though (not my choice, but it's what we currently have). If some results can be posted here, just to make sure that no more changes need to be done, I'd appreiciate it. Note: I still haven't had a chance to come up with a patch for the Calendar and Addressbook categories.
*** Bug 252143 has been marked as a duplicate of this bug. ***
*** Bug 327201 has been marked as a duplicate of this bug. ***
*** Bug 329591 has been marked as a duplicate of this bug. ***
updating patch status
removing old target milestone.
I've been using the Evolution 1.46 patch for a while now, and have been absolutely loving it. Changing the category on the Palm changes the category on Evolution with no problems. Changing the category on Evolution doesn't change the category on the Palm, though. I'm not sure where the issue resides, but I'd love for this patch to be included with Evolution. It's sorely needed for anyone using their Palm and Evolution with GTD.
I've recently upgraded to 2.6.2. It appears the category patch is now standard. Updating categories under Evolution doesn't update the category on the Palm, however. (ie. Changing a cateory from Calls to Computer leaves the category at Calls on the Palm).
*** Bug 380011 has been marked as a duplicate of this bug. ***
Created attachment 80407 [details] [review] unified category support for calendar/todo/memo I've created a patch for all the calendar-related conduits to support categories. For the moment only todo and memo have category support. This patch also moves all the common code for todo, memo and calendar regarding categories to e-util/e-pilot-util.c, thus keeping only the need to maintain 1 time the category code and the same behavior for all the conduits. It changes the behavior of the todo and memo conduits a little. In evolution you can assign more than 1 category to an event which palm can't handle. The current implementation does not handle this and erases all the categories in evolution if you change something on the palm. This implementation should only alter the first category assigned in evolution, leaving the others untouched. This patch also adds support for categories in the calendar, which is currently not implemented. please also not this patch was made after the patch for pilot-link 0.12 was applied: http://bugzilla.gnome.org/show_bug.cgi?id=389664
yay. thanks a lot tom (personally, because this is my best friend's most problematic issue that he currently has with evolution). veerapuram, can this get in for 2.10? "complete syncing" also sounds like a nice evo/gnome marketing argument to me ;-)
Thanks a lot Tom! Sorry I never got back to you on e-mail about the category->ID field. We definitely need to set it (can't leave it unset). Take a look at http://www.access-company.com/developers/documents/docs/conduits/win/Intro_CondBasics.html#996444. This explains that the category ID is used to determine how to synchronize a category. Note that access-company is now the owner of PalmOS. When I originally implemented category synchronization, I always set the ID to lastDesktopUniqueID because I didn't realize what what happening (and hadn't read the documentation). Now, after looking at the documentation as well as the current category IDs in my PalmOS databases, I realize the ID field is always getting set to 128 (which I think you mentioned in an e-mail to the gnome-pilot list). I now have multiple categories with the ID 128, which is probably causing a lot of problems regarding category synchronization. What I would suggest doing to set the ID field is to search through the existing ID fields and find a number between 128 and 255 that's not currently being used. I'm taking the 128 to 255 number from pi-appinfo.h, where it says desktop category IDs should be from 128 to 255, and PalmOS category IDs are from 0 to 127. Aside from needing to set the ID of a new category, I think the patch is good. We might want to consider implementing the category synchronization conflicts from the documentation above. However, there is no meaningful "desktop ID" for Evolution categories so I don't know how we would deal with that.
Oh help, I was wondering why nobody was answering, but it seems I wasn't on the CC list :-S I will look at the documentation link Nathan provides and try to fix the problem. Also because 2.10 is already released it will be hard to get it into it, I'll look into the possibility to make a new patch against evolution 2.10
Please include Contacts/Addresses in this enhancement. I found this bug while trying to figure out why my new Treo 680 does not sync the categories field for my Contacts. Currently all new addresses copied Evo-->Palm during synchronization will show up in the Unfiled category in the Palm no matter what category they are filed under in Evolution, as well as all new addresses copied Palm-->Evo will show up as Unfiled in Evolution no matter what category they are filed under in the Palm. Of course it turns out this feature has never been implemented. So, I am requesting that support for Category synchronization of Contacts be included in the work that is currently happening in this bug. It turns out everyone uses their Palm differently, I for one have never found it useful to assign categories to calendar entries. But keeping my Contacts organized hinges on my ability to divide them into several categories. Thanks for reading my 2 cents worth ;-)
Created attachment 86194 [details] [review] unified category support for calendar/todo/memo v2 It took some time, but here is an improved version. The patch is made against evolution 2.10.1 The only thing that's changed is the comment Nathan mentioned, I think it takes this into account now. And bad: I'm sorry for the address implementation for categories. I looked at it, but it's more work than I thought, so for the moment it's not included. But if I can find time again I'll continue my work on the complete rework to the contactsDB instead of addressDB which will contain category support ;-)
Looks great with the change to the desktop ID. Can someone commit it? I hope the new functions can also be used by the existing AddressDB conduit. This conduit will probably have to be supported for quite a while until everyone upgrades to pilot-link 0.12. I might have time to look at the AddressDB conduit in the first week or two of May - I'll only have work to do and no grad school. Also need to fix the compare functions of each conduit (memcmp doesn't work and is the cause of most of the duplicate problems), but that's a completely separate bug.
First of all: most of them are not new functions, they were already existent in the memo and todo conduit, but they are now moved to the e-pilot-utils file as they are the same for the memo, todo and calendar conduit. They are a bit improved though. And for the addressDB: you will not be able just to use these functions: this because of this: +void e_pilot_local_category_to_remote(int * pilotCategory, ECalComponent *comp, struct CategoryAppInfo *category) +{ + GSList *c_list = NULL; + char * category_string; + int i; + e_cal_component_get_categories_list (comp, &c_list); there is no ECalComponent when using the address book, and I also can't find and e_cal_component_get_categories_list alternative for the address book in the EContact structure. I think i will only be possible when you move from the EContact structure to the EVcard structure, which is what I was planning to do for the ContactsDB implementation and the memcmp problem, I have no idea what actually the problem is?
Nice one to be in 2.11.1. Off to you Varadha :)
Whoops! I'd hold off on committing this, as I just found a bug. If this is built as-is, then I get an "unable to instantiate e-address conduit" in the gpilotd-control-applet window (main settings window). The reason for this is that libeconduit.so (which all conduits must load when they load themselves) depends on e_cal_component_free_categories_list because of the new category implementation. As soon as I instantiate the settings windows for e-calendar, e-todo or e-memos, then this problem goes away. This makes sense, as e_cal_component_free_categories_list is defined in libecal, and the e-address conduit is not going to load libecal. However, the Calendar, Tasks, and Memos do, so after they're loaded the gpilotd-control-applet knows how to dynamically link to the function. This all lets the e-address conduit load. We also run across this problem with gpilotd if only the e-address conduit is enabled (i.e. gpilotd won't load libecal because none of the calendar-based conduits are loaded). I think it's clear that the categories will have to be moved to some other library (or libraries) that the e-address conduit isn't using. Maybe the code is duplicated as in my original implementation (though I don't really like that idea, it's easiest). The other (better) option would be to create a libecalconduit.so file that has common functions between the e-calendar, e-todo, and e-memos conduits. That may be the better option for the long-term. Any comments? suggestions? Nathan
Aha, now I understand the problem. I do get this error too, but as it was complaining about e-address conduit I thought this error was triggered by something else, as the address conduit was the only one I didn't touch. I did also try to find out what the problem was, but I wasn't able to find it. Now with Nathan's explanation it's all clear, my patch is actually causing problems :-( So the code I added to e-pilot-util.c will have to be replaced to solve the problem. I think the solution from nathan to add a libecalconduit.so file is the best solution. The file should live in the ./calendar/conduits directory, right? Btw Nathan: you know how to choose the right timing, I just finished writing my masters thesis yesterday, so I have some time now. I'll see if I can come with a new patch...
Not sure I understand the problem yet. Does libeconduit end up with an undefined symbol of 'e_cal_component_free_categories_list' ? If so, surely the correct solution is to ensure libeconduit has a dependency on libecal. Then whenever libeconduit is loaded the symbols will get resolved. This may require changes to the evo make code, but nothing else. Likewise for any other undefined symbols. Or do I have the wrong end of the stick here?
it appears so: ld libeconduit.so ld: warning: cannot find entry symbol _start; not setting start address libeconduit.so: undefined reference to `e_cal_component_set_categories_list' libeconduit.so: undefined reference to `convert_FromPilotChar' libeconduit.so: undefined reference to `e_cal_component_get_categories_list' libeconduit.so: undefined reference to `convert_ToPilotChar' libeconduit.so: undefined reference to `e_cal_component_set_categories' libeconduit.so: undefined reference to `e_cal_component_free_categories_list' I don't know what will be the best solution: make libeconduit depend on libecal or fix my patch... The convert_FromPilotChar function also seems a problem, but that's a function from pilot-link, defined in pi-util.h
There's no good reason for those undefined symbols: libeconduit should be linked against libpisync and libecal to fix these issues. Don't create another library unless there's a good reason. Code common to more than one conduit should be put in libeconduit, no? It's important to get the linking right at build time. As things stand, there's no way for the linker to know whether "convert_FromPilotChar" should come from pilot-link 0.11.8 or pilot-link 0.12.x. It's important to get the right library or you'll get a crash at runtime. The only time there should be undefined symbols is if the symbols are going to come from libraries dynamically loaded programatically at runtime, which isn't the case here. The source of all the symbols is known at build time.
I don't believe we should link libeconduit against the libecal API. The code in the e-util directory of evolution is meant to be component-independent. If the code is not common to ALL components, then it shouldn't be in that directory. I think the correct approach is to move the functions to somewhere else. One option is to create another library in the conduits directory. Another option could be to add an e-cal-pilot-util.c file to libecal in the evolution-data-server and put the functions in there. We'd probably have to get approval from the Evo libecal maintainers, but since it wouldn't break the API (only add to it), this would probably be OK. The more I think about this option, the better I like it: no new library, and these functions really are libecal-like (there's already an e-cal-util.c file, which is similar to this). With regards to "convert_FromPilotChar", we should probably be linking against libpisync with the libeconduit library. I just ran the linker with -lpisync, and it got rid of the ld warnings. As we determine if we're linking against pilot-link 0.11 or 0.12 at compile-time, I think this would be OK to do. From your comment, Matt, it seems like you wouldn't expect this to work (or at least it might seem to work and then fail later). Is there something I'm missing?
Well, we have three solutions then: 1) put the code in libeconduit: + library is already there - not component-independent anymore 2) create a library for todo, memo and calendar + These three conduits are very similar, sharing some code in a separate file might be useful - requires a new library 3) put it in libecal in e-d-s I don't really see pros and cons Actually the problem is the following: there are 4 conduits in evolution: address book, calendar, todo and memo. Address book is depending on libebook, where the other three require libecal. The implementation for the moment is that every conduit has it's own file, and then there are some files common for the 4 conduits. In this point of view I think option 2 is the most logical, as I think there may be more code duplication than the code I found, and it may become useful later. But as I'm not an evolution expert and I've never worked on such a big project before, I think I'll need some advice on this :-)
The reason I'm thinking option 3 is the better option is because libecal could actually be the library mentioned in option 2. libecal is meant for this type of purpose, so it has the plus of 2 (no code duplication), but not the downside (no new library needed). When duplicate code is taken out in the future (if that happens), we could easily put it in libecal as well. The downside to putting it in libecal, is that we need to be VERY sure of the API ahead of time. Once it's in the API, we don't want to be changing it.
I guess it's a question for the evo team, really. They should be able to tell you where the code should go. AFAICT e-d-s doesn't currently have any pilot-link or gnome-pilot dependencies so they may be unwilling to add any. I guess the code depends on libecal, libeconduit, and pilot-link. Are there any gnome-pilot dependencies? Maybe option 2 is the right one after all. Either that, or libeconduit loses its component-independence. It's up to you evo people, really! I don't have strong feeling as to where it should go, as long as all symbols are linked after building. As to Nathan's question, I didn't mean to imply there should be any runtime problems with libpisync. As long as the code is in a library that is linked against libpisync at build time (i.e. ldd lists libpisync as a dependency) all will be well. [ as an aside: I recently raised a bug against pilot-link because they didn't increment the libpisync version from 0.11.8 to 0.12.x. This means that the linker can't distinguish between them... oops.]
Hmmm... I hadn't looked at the specific gnome-pilot and pilot-link dependencies. There aren't any gnome-pilot dependencies, but the pilot-link structure, CategoryAppInfo, is used. Sounds like option 2 is the best way to go after all.
Created attachment 89566 [details] [review] unified category support for calendar/todo/memo v3 Okay, third try :-D Now the common code for the todo/memo/address conduit is no longer added to e-util/e-pilot-util but to a new library in calendar/conduits/common. Please take a look at it and feel free to make suggestions, but it's working fine here, no more unresolved symbols anymore. This patch is made against svn revision 33610
Tom, one more problem (found over at bug 429423): we need to use the e_pilot_utf8_from_pchar and e_pilot_utf8_to_pchar functions when getting/setting the categories. Otherwise, sync will fail when non-US-ASCII characters are used. I believe this is already being done on all other fields. I'll update the patch you've submitted with the appropriate calls. I'll also check to see if the Addressbook conduit needs to be updated (I know categories don't work there very well, but I'll still look at it).
OK, sounds good for me. Thanks Nathan
As far as I can tell there is no patch of the latest changes build against 2.10.1. The last changes are patched against svn revision 33610. Will this come in future or can I somehow apply this patch myself? I would like to sync categories while at the same time use the version that is supported by the current stable of ubuntu. Thanks, Max
max: feel free to manually backport, then you can try to apply the patch yourself, but in general it's too much work (and wasting time) to do this for an obsolete version like 2.10.1 (current stable version is 2.10.3.1)
I hope this patch will be applied to the trunk, then you don't have to apply it yourself. Nathan: you said you would apply some changes before it can be committed, are you still working on it, and do you think you will get it ready before the next stable release?
Chen, Varadhan: Any chance of getting this in to trunk?
This would be huge. I could really need this feature right now. Max
(In reply to comment #74) > I'll update the patch you've submitted with the appropriate calls. I'll also > check to see if the Addressbook conduit needs to be updated (I know categories > don't work there very well, but I'll still look at it). nathan, any news here, so we could perhaps get this reviewed for 2.12?
(In reply to comment #77) > max: feel free to manually backport, then you can try to apply the patch > yourself, but in general it's too much work (and wasting time) to do this for > an obsolete version like 2.10.1 (current stable version is 2.10.3.1) > Ok, I had the category sync going ok for a couple of times but now it just keeps crashing. One reason might be special character/umlaut thing which I can't cure for the moment. But one more thing: I think I have read somewhere that the number of categories is limited on the palm. Watching gpilotd I, it says it gets the categories from ~/.evolution/categories.xml but I think the wheather applet writes to the very same file so it reports a whopping 21 categories. Could this pose a problem? -- (gnome-pilot:9946): e-data-server-DEBUG: Loading categories from "/home/mhoffman/.evolution/categories.xml" (gnome-pilot:9946): e-data-server-DEBUG: Loaded 21 categories *** stack smashing detected ***: ./gpilotd terminated Aborted (core dumped) -- Max
I'm sorry I've let this go so long. I had completely forgotten this in the midst of moving. When does a patch need to be in to get released into 2.12? I can definitely get a patch within the next week. If there's a rush I can probably get it in Tuesday night (Aug 21).
Nathan, I assume that this patch doesn't include any UI change, in that case I prefer you to review and push it asap for 2.11.91 (Monday), preferably before Friday evening in svn. Any new strings that are added have to be announced to gnome-i18n@gnome.org
Created attachment 94386 [details] [review] Patch for category implementation plus a few other bug fixes Here's the patch (finally). I fixed a few other bugs while I was at it. Here's a list of changes from Tom's v3 patch: 1) Added conversions to and from UTF-8 and the Palm charset (bug 429423) 2) In the ToDo conduit, the due-date was being set even if there wasn't one. For some reason, the "todo.indefinite" field wasn't being checked. 3) Removed code added in bug 349122 that got rid of warnings. Warnings are back in the build unfortunately, but we're stuck with them for now. I've added a note to the bug report explaining what was happening (in short, it crashed). 4) Modified e_pilot_remote_category_to_local() slightly to make it get rid of a potential memory leak (the new_category GSList isn't used anymore - I don't believe it was being freed, and it's not necessary now with the modifications I added). I've run quite a few tests to verify the category functionality works now. Thanks to Tom for all the work put into getting this working.
One other note: unfortunately the Addressbook Conduit still does not sync categories properly. This means this bug can't be closed yet. The addressbook conduit is very different from the calendar-based conduits, hence why it's not included in Tom's patch (and no one has created a patch for it yet).
Setting the patch status. Thanks Nathan for your review and Tom/Nathan for the patch
I got this error while compiling. But Im sure that I have eds installed. gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../e-util -I../../../e-util -g -O2 -Wall -Wmissing-prototypes -Wno-sign-compare -MT libecalendar-common-conduit.lo -MD -MP -MF .deps/libecalendar-common-conduit.Tpo -c libecalendar-common-conduit.c -fPIC -DPIC -o .libs/libecalendar-common-conduit.o libecalendar-common-conduit.c:25:41: error: libedataserver/e-categories.h: No such file or directory In file included from libecalendar-common-conduit.c:26: ../../../e-util/e-pilot-util.h:23:42: error: libedataserver/e-source-list.h: No such file or directory ../../../e-util/e-pilot-util.h:24:37: error: libedataserver/e-source.h: No such file or directory In file included from libecalendar-common-conduit.c:26: ../../../e-util/e-pilot-util.h:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token ../../../e-util/e-pilot-util.h:33: error: expected ')' before '*' token libecalendar-common-conduit.c:28:18: error: glib.h: No such file or directory In file included from libecalendar-common-conduit.c:30: libecalendar-common-conduit.h:4:27: error: libecal/e-cal.h: No such file or directory In file included from libecalendar-common-conduit.c:30:
Your gcc line doesn't look like mine: it's missing all the include files. I don't know why there would be a difference. When I tested the patch (to make sure I had gotten it correct), I removed configure.in and the calendar/conduits directory, updated to the latest revision from SVN, applied the patch, and then ran autogen.sh. The parameters I ran with autogen.sh were: "--enable-maintainer-mode --enable-maintainer-mode --prefix=/opt --enable-nntp=yes --enable-nss=yes --enable-smime=yes --enable-exchange=yes --enable-file-chooser --enable-plugin=base --with-openldap=yes --enable-cairo-calendar=yes --enable-pilot-conduits=yes --with-pisock=/opt" I'll look at Makefile.am to see what may have gone wrong. Here is what my output looks like when I'm compiling: if /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../e-util -I../../../e-util -DORBIT2=1 -pthread -I/opt/include -I/usr/include/libgnome-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-keyring-1 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/libxml2 -DORBIT2=1 -pthread -DDBUS_API_SUBJECT_TO_CHANGE -I/opt/include/libgtkhtml-3.14 -I/opt/include/evolution-data-server-1.12 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/gnome-vfs-module-2.0 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -ggdb -Wall -Wmissing-prototypes -Wno-sign-compare -MT libecalendar-common-conduit.lo -MD -MP -MF ".deps/libecalendar-common-conduit.Tpo" -c -o libecalendar-common-conduit.lo libecalendar-common-conduit.c; \ then mv -f ".deps/libecalendar-common-conduit.Tpo" ".deps/libecalendar-common-conduit.Plo"; else rm -f ".deps/libecalendar-common-conduit.Tpo"; exit 1; fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../e-util -I../../../e-util -DORBIT2=1 -pthread -I/opt/include -I/usr/include/libgnome-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-keyring-1 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/libxml2 -DORBIT2=1 -pthread -DDBUS_API_SUBJECT_TO_CHANGE -I/opt/include/libgtkhtml-3.14 -I/opt/include/evolution-data-server-1.12 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/gnome-vfs-module-2.0 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -ggdb -Wall -Wmissing-prototypes -Wno-sign-compare -MT libecalendar-common-conduit.lo -MD -MP -MF .deps/libecalendar-common-conduit.Tpo -c libecalendar-common-conduit.c -fPIC -DPIC -o .libs/libecalendar-common-conduit.o /bin/sh ../../../libtool --tag=CC --mode=link gcc -ggdb -Wall -Wmissing-prototypes -Wno-sign-compare -o libecalendar_common_conduit.la -rpath /opt/lib/evolution/2.12/conduits libecalendar-common-conduit.lo ../../../e-util/libeutil.la ../../../e-util/libeconduit.la -Wl,--export-dynamic -pthread -L/opt/lib -lgpilotd -lgpilotdcm -lgpilotdconduit -lpisock -lpisync -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnome-keyring -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lbonobo-2 -lbonobo-activation -lgconf-2 -lgmodule-2.0 -ldl -lORBit-2 -lgthread-2.0 -lrt -lgobject-2.0 -lglib-2.0 -Wl,--export-dynamic -pthread -L/opt/lib -lgtkhtml-3.14 -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnome-keyring -lgnomecanvas-2 -lart_lgpl_2 -lpangoft2-1.0 -lecal-1.2 -ledataserverui-1.2 -lglade-2.0 -lebook-1.2 -lgnome-2 -lpopt -ledataserver-1.2 -lxml2 -lgconf-2 -lbonobo-2 -lbonobo-activation -lORBit-2 -lgthread-2.0 -lrt -lhal -lnotify -lgtk-x11-2.0 -ldbus-glib-1 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgmodule-2.0 -ldl -ldbus-1 -lgobject-2.0 -lglib-2.0 gcc -shared .libs/libecalendar-common-conduit.o -Wl,--rpath -Wl,/home/owens81/src/evolution/svn/evolution/e-util/.libs -Wl,--rpath -Wl,/opt/lib/ -Wl,--rpath -Wl,/opt/lib -Wl,--rpath -Wl,/opt/lib/evolution/2.12 -Wl,--rpath -Wl,/opt/lib/ -Wl,--rpath -Wl,/opt/lib ../../../e-util/.libs/libeutil.so -L/opt/lib -L/usr/lib/gcc/i586-mandriva-linux-gnu/4.1.2/../../../ -L/usr/lib ../../../e-util/.libs/libeconduit.so /opt/lib//libgpilotd.so -L/usr/lib/lib /opt/lib//libgpilotdcm.so /opt/lib//libgpilotdconduit.so /opt/lib/libpisock.so /opt/lib/libpisync.so /opt/lib/libgtkhtml-3.14.so /usr/lib/libgnomeui-2.so /usr/lib/libSM.so /usr/lib/libICE.so /usr/lib/libbonoboui-2.so /usr/lib/libgnomevfs-2.so /usr/lib/libgnome-keyring.so /usr/lib/libgnomecanvas-2.so /usr/lib/libart_lgpl_2.so /usr/lib/libpangoft2-1.0.so /opt/lib/libecal-1.2.so /opt/lib/libedataserverui-1.2.so /usr/lib/libglade-2.0.so /opt/lib/libebook-1.2.so /usr/lib/libgnome-2.so /usr/lib/libpopt.so /opt/lib/libedataserver-1.2.so /usr/lib/libxml2.so /usr/lib/libgconf-2.so /usr/lib/libbonobo-2.so /usr/lib/libbonobo-activation.so /usr/lib/libORBit-2.so /usr/lib/libgthread-2.0.so -lrt /usr/lib/libhal.so /usr/lib/libnotify.so /usr/lib/libgtk-x11-2.0.so -ldbus-glib-1 /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libcairo.so /usr/lib/libgmodule-2.0.so -ldl -ldbus-1 /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -Wl,--export-dynamic -pthread -Wl,--export-dynamic -pthread -Wl,-soname -Wl,libecalendar_common_conduit.so.0 -o .libs/libecalendar_common_conduit.so.0.0.0 (cd .libs && rm -f libecalendar_common_conduit.so.0 && ln -s libecalendar_common_conduit.so.0.0.0 libecalendar_common_conduit.so.0) (cd .libs && rm -f libecalendar_common_conduit.so && ln -s libecalendar_common_conduit.so.0.0.0 libecalendar_common_conduit.so) creating libecalendar_common_conduit.la (cd .libs && rm -f libecalendar_common_conduit.la && ln -s ../libecalendar_common_conduit.la libecalendar_common_conduit.la)
Created attachment 94424 [details] [review] Possible fix to build problem Here's a possible fix for the build problem. I added the header file location and string in conduits/common/Makefile.am, as well as changing the LDFLAGS to have the correct values (instead of $(pilot_compile), use -module "-avoid-version $(NO_UNDEFINED)" like the conduits do). Hope this helps.
Srag asked me to test this patch about compiling and it seems to me like working, I tested the last one 94424. I didn't test a functionality, only if it compiles smoothly (./configure... && make && make install).
Sigh, I just noticed that it breaks string freeze with + gnome_pilot_conduit_error (conduit, + _("Could not write pilot's Calendar application block")); If I would remove the _() for g_warnings. Is there a way we can workaround this error with a already present error string? If it is working and compiles well, Im fine to push it. I need to see wth it broke in my machine.
Unfortunately there aren't any other applicable errors that can be used directly. The other two conduits specifically mention ToDo or Memo when writing a similar error message. We could potentially use one of those strings, but the error message wouldn't be correct anymore (referring to the ToDo or Memo conduit while syncing the Calendar is a little weird). If we have to, I guess we could go that route and use one of the existing ToDo or Memo strings. What might be better is to just remove the gnome_pilot_conduit_error() call for now, and then remove the _() from around the WARN() string two lines above that. This error is very unlikely; if the user got this far, the application should be able to write to the application block (the only limitation being the app block must be < 64K, which the Calendar-specific App Block doesn't go beyond). In the case that the error occurs, gpilotd (the main syncing app) can be run from the command line to view the WARN error. This functionality has been in the Memo and ToDo Conduits for a while, and I've never seen a user report this error being shown. I would feel comfortable taking it out of the GUI and only having a command-line error be shown.
Nathan, then go ahead and commit it removeing _() in warn and commenting the error and we can uncomment during the next unstable development. Thanks every one for all the great help.
I still don't have commit privileges (I've never really tried to get them). Can someone else commit it with the _() removed as discussed? Thanks.
Created attachment 94845 [details] [review] committed evo patch I committed this patch to trunk. Committed revision 34162. It's a bit changed from that attachment #94424 [details]. I kept the bug opened because of uncommenting an error message and do it localized after a string freeze. Please add ChangeLog entries next time. Thanks.
Created attachment 94846 [details] [review] committed evo patch part two I'm so sorry, I forget that you added there new files and I didn't put them to svn, so here is a rest of your patch. (btw, I noticed that the Makefile.am is a bit larger from that yours and I don't have there such lines like "Properties added...". Nevertheless, Committed revision 34163.
Removing configure warnings I added there (the way why the Makefile.am was larger for me). I'm sorry for that. Committed revision 34164.
Even the libecalendar-common-conduit.[ch] are larger than usual (duplicate contents inside the same file) Fixed that in head. Thanks for every one.
so what is the status here? do we have complete syncing now (and can we close this as fixed)? can somebody (nathan?) write one or two sentences which improvements this means for an average user (so that an average user and non-coder understands)? yes, that short text could become part of the gnome 2.20 release notes. ;-)
The patch I made add category syncing for the calendar. This was already available in for the todo and memo conduit, but both conduits had their own implementation. Now there is one implementation for category syncing that is shared for the memo, todo and calendar conduit. The only thing that the user will notice is that the calendar now sync categories, the behavior of the todo and memo conduit should remain the same. And this bug can't be closed as the address book doesn't have category synchronization. The mechanism there is very different so it will require another way to synchronize it. And if I'm not wrong we need to switch to the palm os 5 database structure for it for the address book...
ooops, okay. thanks for the clarification!
Bumping version to a stable release.
I am really surprised and disappointed this bug, which was identified in January 2001, is still an issue in May 2008. I moved from KDE-PIM to Evolution just to be able to capture my contacts list (with categories) to a my Kubuntu-Hardy system. Well I got all my contact data but w/o category data. Is there not a work-around anyone can offer? Will this ever be fixed? I guess I'll have to return to my quest of syncing my Palm with Kontact, something I've not been able to do ever since i installed Hardy. Please, someone make an effort to repair/patch/fix Evolution so contact categories will migrate during a sync operation.
I have a patch for the addressbook category syncing which I'll aim to submit to evolution-patches list (and this bug) over the weekend. I need to extricate this particular item from broader address-conduit fixes I've been developing.
Created attachment 120438 [details] [review] category syncing for addressbook-conduit patch to add category syncing to addressbook-conduit. Also fixes given-name/family-name syncing bug.
ping! This should probably not be classified as 'future' anymore.
TMs don't really have any meaning for Evo. But indeed, a review would be nice. Varadhan?
Ping!
Hi, It would nice to see this category syncing completed. Especially because the fix is available, all it needs is to get submitted. Nice work Matt, I hope it gets in soon.
grmpf... Srini? Varadhan? Can this please get in in the next 2 weeks before API freeze?
Another ping! Note that there are no API changes in this patch. Changes are limited to a single file, address-conduit.c. I should have mentioned that the patch also fixes bug #269342.
Matt, I'm not very familiar with the conduits code but I see nothing objectionable in the patch. Go ahead and commit it. In the future, if your conduit patches are not getting reviewed in a timely manner, I'd say to treat that as implicit acceptance and commit them. That code isn't actively maintained and I don't know how many developers are left that are familiar with it. Might just be no one feels qualified to review them.
I don't like the two g_warning strings, IMO they should not be translatable. And a third one (though it is commented) should probably also not be marked for translation.
Thanks for the patch, Matt. It looks fine to commit. Can you commit the patch with a change - g_message strings need not be translated. Thanks again for the patch.
Thanks for the reviews. I've committed the patch to the trunk, after removing translation markup on g_warning strings. Marking bug fixed.
Thanks everybody. Especially to Matt for his patience. :)
Sorry, but how can I know if my Evolution+Conduits version has this fixed? The pilot-conduit continue asking me which category I want to sync. And, what has been fixed? Only the category syncing in Address Book or category syncing is fixed on all evolution items? (Todos, Calendar, ....) Despite my doubts, thanks for finally solving this.
(In reply to comment #118) > Sorry, but how can I know if my Evolution+Conduits version has th It should be included in 2.26.