Re: [Evolution-hackers] If an account changes, who regenerates the services?
On 10/19/2010 03:52 PM, Matthew Barnes wrote: On Tue, 2010-10-19 at 14:10 -0500, Federico Mena Quintero wrote: I'm trying to unwind some code in Camel and in Evolution. The problem I have is that if you change an email account's extra options (e.g. imapx's apply filters to new messages), then those changes don't take effect until you restart Evolution. That option is a filter parameter in a CamelURL - the URL for the IMAPX service. As far as I can tell, the only place where an IMAPX service gets this URL is at construction time. However, a breakpoint at imapx_construct() only gets hit when I start up Evolution, not afterward (e.g. after changing the account's options in the account editor). There is a lot of code around the account editor to apparently propagate changes. But I'm rather lost in the structure. em-account-editor changes the EAccount in emae_commit(), by calling e_acount_import(). Then it does e_account_list_change(). Both of those functions emit signals about something changing. That's where I'm lost. Does anyone know what links both parts of the code - the account editor and the actual construction of Camel services? The 100,000 ft. answer is that trying to represent an account and its various options as a URL string is a broken concept and another deep design flaw in Camel. Change any option that results in a different URL string and Camel treats it as a completely new account, sets up all new cache storage for it, and doesn't even clean up the old cache. This isn't actually true... or at least it wasn't at one point. There used to be (still is?) a CamelService comparer function that decides if 2 CamelURLs are for the same service. Each provider can override this method. All that needs be done is ignore parts of the url that are insignificant (like the query, for example). The one area where this fell flat was if things like the port changed. One solution to Federico's original query is that you could use the camel_object_setv() API to set new parameters on an existing CamelService (sorta like GObject's getv/setv). I think that currently, a number of options are part of the URL and so changing the URL might make the CamelService want to disconnect/reconnect (assuming it works at all, this part of Camel was never finished). You could modify the service setv() code to be able to diff the URLs and see what portions changed to decide whether or not the service needed to reconnect or not and update state. Camel needs to have some kind of account object onto which meta-data can be added and altered. Sure, but you still have the same problems you have now, just in a different object :-) Jeff ___ 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] If an account changes, who regenerates the services?
Hi, all, I'm trying to unwind some code in Camel and in Evolution. The problem I have is that if you change an email account's extra options (e.g. imapx's apply filters to new messages), then those changes don't take effect until you restart Evolution. That option is a filter parameter in a CamelURL - the URL for the IMAPX service. As far as I can tell, the only place where an IMAPX service gets this URL is at construction time. However, a breakpoint at imapx_construct() only gets hit when I start up Evolution, not afterward (e.g. after changing the account's options in the account editor). There is a lot of code around the account editor to apparently propagate changes. But I'm rather lost in the structure. em-account-editor changes the EAccount in emae_commit(), by calling e_acount_import(). Then it does e_account_list_change(). Both of those functions emit signals about something changing. That's where I'm lost. Does anyone know what links both parts of the code - the account editor and the actual construction of Camel services? Thanks, Federico ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] If an account changes, who regenerates the services?
On Tue, 2010-10-19 at 14:10 -0500, Federico Mena Quintero wrote: I'm trying to unwind some code in Camel and in Evolution. The problem I have is that if you change an email account's extra options (e.g. imapx's apply filters to new messages), then those changes don't take effect until you restart Evolution. That option is a filter parameter in a CamelURL - the URL for the IMAPX service. As far as I can tell, the only place where an IMAPX service gets this URL is at construction time. However, a breakpoint at imapx_construct() only gets hit when I start up Evolution, not afterward (e.g. after changing the account's options in the account editor). There is a lot of code around the account editor to apparently propagate changes. But I'm rather lost in the structure. em-account-editor changes the EAccount in emae_commit(), by calling e_acount_import(). Then it does e_account_list_change(). Both of those functions emit signals about something changing. That's where I'm lost. Does anyone know what links both parts of the code - the account editor and the actual construction of Camel services? The 100,000 ft. answer is that trying to represent an account and its various options as a URL string is a broken concept and another deep design flaw in Camel. Change any option that results in a different URL string and Camel treats it as a completely new account, sets up all new cache storage for it, and doesn't even clean up the old cache. Camel needs to have some kind of account object onto which meta-data can be added and altered. But to actually answer your questions, CamelStores are loaded from EAccounts at startup in mail/e-mail-store.c:mail_store_load_accounts(). Once loaded, the CamelStore object is added to the EMFolderTreeStore, which serves as the model for the folder tree view in the side bar. EMFolderTreeStore responds to the account-changed signal by removing the CamelStore object associated with the changed EAccount, and loading a new one. I'm not exactly sure how that's handled within Camel, but my guess is this is the source of the problem. That's the only place I'm aware of that anything meaningful happens. The other account-changed handlers are for custom widgets that just list the accounts, like EAccountComboBox which appears in the composer. Hope this helps. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
