Re: [Evolution-hackers] Proposed fix for bug 311512
On Thu, 2007-04-26 at 07:50 +0100, Karl Relton wrote: On Wed, 2007-04-25 at 09:48 -0400, Jeffrey Stedfast wrote: I'm not sure I'd call it get_filter_thread() because it's not getting a thread, all it is really doing is getting you a 'wait' id (and ugh, the new session_thread_wait() just busy-waits?) I think if this type of solution is really the best way of doing it, then I think it'd be better to just have a CamelFolder function (camel_folder_wait_filtering()? I dunno)that waits for the filtering operation to finish rather than providing a higher level with a wait id that it should never have to know or care about. Agreed - if this is the 'best way', I'll redo the patch as you suggest. But better still would be to trap the folder_changed signal for folders that are currently in the process of filtering (CamelFolder already listens for this event in order to invoke the filtering iirc, so just stop the signal from propagating) and re-emit it later when filtering is complete (obviously with the updated changes). Yes - I had thought of this too. The trouble is with the current code its not quite so simple AFAIK. The filtering that takes place is actually launched from the folder_changed() function in camel-folder.c. In other words, it is launched from the folder_changed event handler itself. Now I may be wrong here, but my assumption is that both evo and e-d-s register event handlers on this type of event - so that when such an event occurs code in both evo and e-d-s is executed ... perhaps even in parallel (in their own threads)? not completely correct... when you trigger an event on a CamelObject, it first fires the prep callback, which is what camel-folder.c:folder_changed() is (note that it returns bool) A prep event handler is the first handler called (event handlers are fired sequentially, in order of connection - /not/ in parallel) and gets to decide if the event propagates by returning TRUE (or FALSE if it should be blocked - that's how freeze/thaw works). If this is the case, then it is effectively too late to 'trap' the event, because evo will already be processing it. all the event handler has to do is return FALSE to block other event handlers from firing :) Thus (AFAICS) even if camel is in a 'freeze' for folder_changed events, evo will still be firing on every folder_changed occurence. only if folder_changed() returns TRUE - folder_changed() is what checks if the folder is in a freeze state, and if it is blocks further events from firing (by returning FALSE). You have da powah! One way to solve that would be to change things so that evo only fires when camel folder_changed stuff has really done: effectively at the end of a freeze AND filtering. That could be done by introducing a new event and making evo trigger off that perhaps? unnecessary. all the tools are already available :) That would be a much cleaner way of doing it. Jeff Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Proposed fix for bug 311512
On Thu, 2007-04-26 at 09:29 -0400, Jeffrey Stedfast wrote: Yes - I had thought of this too. The trouble is with the current code its not quite so simple AFAIK. The filtering that takes place is actually launched from the folder_changed() function in camel-folder.c. In other words, it is launched from the folder_changed event handler itself. Now I may be wrong here, but my assumption is that both evo and e-d-s register event handlers on this type of event - so that when such an event occurs code in both evo and e-d-s is executed ... perhaps even in parallel (in their own threads)? not completely correct... when you trigger an event on a CamelObject, it first fires the prep callback, which is what camel-folder.c:folder_changed() is (note that it returns bool) A prep event handler is the first handler called (event handlers are fired sequentially, in order of connection - /not/ in parallel) and gets to decide if the event propagates by returning TRUE (or FALSE if it should be blocked - that's how freeze/thaw works). If this is the case, then it is effectively too late to 'trap' the event, because evo will already be processing it. all the event handler has to do is return FALSE to block other event handlers from firing :) Thus (AFAICS) even if camel is in a 'freeze' for folder_changed events, evo will still be firing on every folder_changed occurence. only if folder_changed() returns TRUE - folder_changed() is what checks if the folder is in a freeze state, and if it is blocks further events from firing (by returning FALSE). You have da powah! One way to solve that would be to change things so that evo only fires when camel folder_changed stuff has really done: effectively at the end of a freeze AND filtering. That could be done by introducing a new event and making evo trigger off that perhaps? unnecessary. all the tools are already available :) Excellent - many thanks for correcting me on my understanding. I'll look into it more to see how this can be worked up. Give me a couple of weeks, and I'll come back if I find I need more understanding. Karl ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GNOME Roadmap - Information Request for evolution-data-server
Dear maintainer, GNOME 2.18 was released ~1 month ago, and we've all started to focus on the next development cycle. A new roadmapping process has been proposed[1] to know our short-term and long-term plans. The goal is to compose a GNOME-wide roadmap for the next stable releases. And we need your help to do this. It's important that you take a few minutes to reply to the following questions before May 7. - What are your plans for GNOME 2.20 (next 4 months, before feature and UI freezes)? - What are your plans for GNOME 2.22 (next year)? - Do you have plans for a future release? - Do you have any goals from 2.18 that were not achieved? Why? - Is there something that is really missing in our infrastructure or platform that would help you? - Do you have plans to work on other modules not maintained by you? What are they? - Do you have any GNOME-wide goals suggestions for the next releases? You can reply those questions in two ways: you can directly create a wiki page for your module's roadmap or you can just reply this message to [EMAIL PROTECTED] To create the wiki page, follow the instructions: 1. Create a wiki page under http://live.gnome.org/RoadMap/ModuleName, where ModuleName is a wiki word version of your module (i.e Gedit, LibGnome, GnomeVfs, etc). You can use this template for the wiki page initial content: http://live.gnome.org/RoadMap/ModuleTemplate 2. Add a link to the new page in http://live.gnome.org/RoadMap/Modules and set the status column to Info accordingly. You can keep track of the roadmapping process for your (and other) modules at: http://live.gnome.org/RoadMap/Modules For more information about the roadmap process, go to: http://live.gnome.org/RoadMap/Process For more information about our schedule, go to: http://live.gnome.org/Schedule Thanks for your contribution! The Roadmap Gang [1] http://mail.gnome.org/archives/devel-announce-list/2007-March/msg00011.html ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GNOME Roadmap - Information Request for evolution
Dear maintainer, GNOME 2.18 was released ~1 month ago, and we've all started to focus on the next development cycle. A new roadmapping process has been proposed[1] to know our short-term and long-term plans. The goal is to compose a GNOME-wide roadmap for the next stable releases. And we need your help to do this. It's important that you take a few minutes to reply to the following questions before May 7. - What are your plans for GNOME 2.20 (next 4 months, before feature and UI freezes)? - What are your plans for GNOME 2.22 (next year)? - Do you have plans for a future release? - Do you have any goals from 2.18 that were not achieved? Why? - Is there something that is really missing in our infrastructure or platform that would help you? - Do you have plans to work on other modules not maintained by you? What are they? - Do you have any GNOME-wide goals suggestions for the next releases? You can reply those questions in two ways: you can directly create a wiki page for your module's roadmap or you can just reply this message to [EMAIL PROTECTED] To create the wiki page, follow the instructions: 1. Create a wiki page under http://live.gnome.org/RoadMap/ModuleName, where ModuleName is a wiki word version of your module (i.e Gedit, LibGnome, GnomeVfs, etc). You can use this template for the wiki page initial content: http://live.gnome.org/RoadMap/ModuleTemplate 2. Add a link to the new page in http://live.gnome.org/RoadMap/Modules and set the status column to Info accordingly. You can keep track of the roadmapping process for your (and other) modules at: http://live.gnome.org/RoadMap/Modules For more information about the roadmap process, go to: http://live.gnome.org/RoadMap/Process For more information about our schedule, go to: http://live.gnome.org/Schedule Thanks for your contribution! The Roadmap Gang [1] http://mail.gnome.org/archives/devel-announce-list/2007-March/msg00011.html ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
