Re: [Evolution-hackers] Error reporting changes
On Mon, 2009-12-07 at 14:41 -0500, Reid Thompson wrote: On Mon, 2009-12-07 at 12:37 -0600, Jonathon Jongsma wrote: Quick follow-up to this: I was convinced by a couple of people that we'd probably want EAlert to be a GObject, so I bit the bullet and just did it. In addition, I factored out the convenience dialog functionality and created a GtkDialog subclass called EAlertDialog. This means that there are a couple additional changes since I wrote this mail. The most important ones for developers and plugin authors: - e_alert_free() no longer exists. use g_object_unref() - to use the dialog functionality, include e-alert-dialog.h rather than just e-alert.h - e_alert_new_dialog() - e_alert_dialog_new() Also, there's one little picky cleanup that I snuck in along with those changes. e_alert_newv() was renamed to e_alert_new_valist() to be more consistent with other API in glib (e.g. g_object_newv() takes an array and a length vs g_object_new_valist() which takes a va_list) Evolution, evolution-mapi and evolution-exchange should all be up-to-date with these changes in git. If you have a plugin that's out-of-tree, it may need to be updated. if i wished to attempt to update evolution-remove-duplicates to git head http://www.gnome.org/~carlosg/stuff/evolution/ is there an up to date example for plugins which of the current plugins would best serve as a reference evolution-remove-duplicates added an item to the right click menu that checked for duplicates within selected emails -- i.e. select a folder, CTRL-A, right click, select remove duplicates,... Sorry, I missed this message originally since it got caught by my spam filter for some reason. From a brief look, the only changes you would need to make related to the error/alert stuff would be: - you would need to include e-alert-dialog.h instead of e-error.h. - instead of e_error_run(), you would use e_alert_run_dialog_for_args() If you need any more help, let me know. -- Jonathon Jongsma jonathon.jong...@collabora.co.uk ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error reporting changes
On Mon, 2009-11-30 at 14:07 -0600, Jonathon Jongsma wrote: I just pushed a branch to master that changes how errors are reported. This is part of a bigger effort to isolate the front end from the backend, but it's just a small first step. In general, errors have been presented directly to the user (as dialogs) as soon as they happened. This is demonstrated by the fact that e_error_new() returned a GtkDialog*. This is problematic for a few reasons. The first being that it's not always desirable to show an error as a dialog (for instance, we might want to display them in the future in a GtkInfoBar widget or something similar). In addition, it makes it very difficult to separate the backend functionality from the UI, or to let the calling function make a policy decision about whether the error should be displayed or handled in some other way. So, as a first step to fix this, I've created a new 'object' (really just a plain struct right now, but in the future it could be a proper GObject if we thought it was useful) called EAlert. I chose EAlert rather than EError based on Matthew Barnes advice since evolution often uses this infrastructure to present general informative messages, not only errors. I have kept the convenience API in place to create / display a dialog directly, but the function names will be a bit different. For instance, where you previously used e_error_new(), you can now achieve the same thing with e_alert_new_dialog_for_args() (the _for_args() is to distinguish it from e_alert_new_dialog() which accepts a EAlert* object -- if you can think of a better name for this function, feel free to suggest one). Where you previously used e_error_run(), you can now do the same thing with e_alert_run_dialog_for_args() (same note about function naming as above). However, my goal is to phase out use of these dialog-related helper functions. The plan is that in the future, instead of reporting errors directly, functions that can fail will take a EAlert** parameter and return a newly allocated EAlert object describing the situation (i.e. the same idiom as GError). The calling function can then determine how to handle or present that to the user. I started changing the files in filter/ to use the design I mentioned in the previous paragraph, so for example, the function: e_filter_element_validate(EFilterElement *element, GtkWindow *parent) became: e_filter_element_validate(EFilterElement *element, EAlert **alert) Other parts of the tree have only been changed to use the equivalent helper functions mentioned above. Quick follow-up to this: I was convinced by a couple of people that we'd probably want EAlert to be a GObject, so I bit the bullet and just did it. In addition, I factored out the convenience dialog functionality and created a GtkDialog subclass called EAlertDialog. This means that there are a couple additional changes since I wrote this mail. The most important ones for developers and plugin authors: - e_alert_free() no longer exists. use g_object_unref() - to use the dialog functionality, include e-alert-dialog.h rather than just e-alert.h - e_alert_new_dialog() - e_alert_dialog_new() Also, there's one little picky cleanup that I snuck in along with those changes. e_alert_newv() was renamed to e_alert_new_valist() to be more consistent with other API in glib (e.g. g_object_newv() takes an array and a length vs g_object_new_valist() which takes a va_list) Evolution, evolution-mapi and evolution-exchange should all be up-to-date with these changes in git. If you have a plugin that's out-of-tree, it may need to be updated. -- Jonathon Jongsma jonathon.jong...@collabora.co.uk ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] should git head install e-error.h
On Fri, 2009-12-04 at 10:00 -0500, Reid Thompson wrote: git head contains e-error.h here /home/rthompso/evo-git-head/evolution-data-server/addressbook/libebook/e-error.h previous versions of evo installed this header somewhere in $PREFIX/ ala opt/evo.old/include/evolution-2.30/e-util/e-error.h Head apparently does not do this for me rthom...@raker~/evo-git-head/remove-duplicates-plugin-0.0.4 $ find /opt/evo -name e-error.h rthom...@raker~/evo-git-head/remove-duplicates-plugin-0.0.4 Should it? See this message from last week: http://mail.gnome.org/archives/evolution-hackers/2009-November/msg00049.html -- Jonathon Jongsma jonathon.jong...@collabora.co.uk ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Filtering and mail split
On Wed, 2009-12-02 at 19:23 -0500, Matthew Barnes wrote: The overall design of the filtering classes has always seemed a little backwards to me. We need to be generating rule element widgets from an S-expression, not generating the S-expression from rule element widgets. I have not studied the ESExp API very closely yet so perhaps it already provides what I'm about to suggest, but it seems like what's missing here is an Abstract Syntax Tree (AST). An AST is just a simple tree of nodes consisting of not much more than a type code and a string value. It's not bound to S-expressions or any other syntactic form. We would need the following capabilities: - Generate an AST from an S-expression string. (fairly complex, but maybe ESExp already does this?) - Build an S-expression string by walking over the AST. (dead simple) - Build an editing interface from an AST. (doable, but probably fairly complex -- never tried this) - Modify the AST to reflect changes in the editing interface. (should be simple if done right) I'm of the opinion that most of the XML filter definition should be junked, except perhaps for the partset stuff but that could just as easily be a GtkBuilder spec. A simple way to store the rules then is to save each rule to a separate file in a dedicated directory. Each file would contain an S-expression describing the rule, and the file name would be the rule name. We would also want to track the rule order in some kind of index file somewhere. The backend's job is pretty easy then. It just slurps up files from the agreed upon directory and also reads the index file for the rule order, and hands them off to the filter or search driver as necessary. (We really should be handing an AST off to the drivers, not an S-expression string. S-expressions would then become an arbitrary choice of storage format, and could be much more easily swapped out for something else if a standard ever emerges. But whatever.) The backend might want to also monitor the directory and index file for change notifications from the frontend and just re-slurp everything when something changes. The frontend's job is considerably harder, but I think most of the pieces are there already. They just need to be glued together different. I do have some experience at language parsing from a past life, so maybe I could be of some help here beyond just pitching lofty ideas from the peanut gallery. I like the concept in general, but I think the S-expression (or AST representing the s-expression) is not enough to properly re-construct a filter rule for editing. Consider the following example (yes, it's slightly contrived, but the point is still valid I think): User creates one filter with the following rule part: - Sender contains foo - evolution builds this into the following s-expression: (and (match-all (header-contains From foo))) User creates a second filter with 2 rule parts: - Specific Header From contains foo - evolution builds this into the exact same s-expression: (and (match-all (header-contains From foo))) If we only saved the s-expression to disk and then tried to build an widget to edit this filter, there would be no way to determine whether to use the 'sender' filter part or the 'header' filter part without some additional context. -- Jonathon Jongsma jonathon.jong...@collabora.co.uk ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Filtering and mail split
On Thu, 2009-12-03 at 20:35 +0530, Srinivasa Ragavan wrote: On Thu, Dec 3, 2009 at 3:48 AM, Jonathon Jongsma jonathon.jong...@collabora.co.uk wrote: As some of you may know, I've been looking into moving mail down to the e-d-s level. As a first step, I'm figuring out where to draw the line between the front end and backend. At the moment, I'm focusing on filtering. I think that the filtering functionality clearly belongs in the backend (we want to filter emails as they come in regardless of whether the UI is running or not). The thing I'm trying to figure out right now is what that means for the filter-related classes within evolution (i.e. the stuff in the filter/ directory). My first instinct was that these classes belonged in the backend since that is the part that should be doing the filtering. However, as I looked at it more, I wasn't so sure, and I'd really appreciate insight from people who might have a longer history with this code than I do. (FYI, while I was getting more familiar with the filter code, I wrote up some documentation that you might find helpful: http://live.gnome.org/Evolution/Filters) Excellent job in documenting it. Even more great, because you kept it at lgo. I'm not gonna suggest one of the below but I'm going to think aloud, shut me if its crap. Why should the UI be from the frontend, the Evolution ? If my mail runs in EDS, which reads filters from a xml file, may be as a small capplet/lib/bin with the backend with the UI to launch the filter manager. Independent of Evolution, may be Anjal directly can launch it. Or if we have account setup from Control center as a capplet, then we could launch the filter/rule manager independent of Evolution itself. Is that too much to ask for? It could simplyfy everything? Do we have a tight need of any Evolution components for Filters? I just don't remember, but even if there is, we should try to have it like this IMO -Srini Yes, it's a valid question. Let me quote one thing from my original mail that wasn't emphasized very well so you may have missed it: (note that when I say 'frontend', it may be the MUA itself, or it may be a helper client library like some future libedsmailui library): So my thought was that maybe we would have a libedsmailui utility library (similar to something like libedataserverui) that would implement these filter editing dialogs, etc. Then evolution and anjal could both use them by simply linking to this UI utility library. Does that address your concerns? -- Jonathon Jongsma jonathon.jong...@collabora.co.uk ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Error reporting changes
I just pushed a branch to master that changes how errors are reported. This is part of a bigger effort to isolate the front end from the backend, but it's just a small first step. In general, errors have been presented directly to the user (as dialogs) as soon as they happened. This is demonstrated by the fact that e_error_new() returned a GtkDialog*. This is problematic for a few reasons. The first being that it's not always desirable to show an error as a dialog (for instance, we might want to display them in the future in a GtkInfoBar widget or something similar). In addition, it makes it very difficult to separate the backend functionality from the UI, or to let the calling function make a policy decision about whether the error should be displayed or handled in some other way. So, as a first step to fix this, I've created a new 'object' (really just a plain struct right now, but in the future it could be a proper GObject if we thought it was useful) called EAlert. I chose EAlert rather than EError based on Matthew Barnes advice since evolution often uses this infrastructure to present general informative messages, not only errors. I have kept the convenience API in place to create / display a dialog directly, but the function names will be a bit different. For instance, where you previously used e_error_new(), you can now achieve the same thing with e_alert_new_dialog_for_args() (the _for_args() is to distinguish it from e_alert_new_dialog() which accepts a EAlert* object -- if you can think of a better name for this function, feel free to suggest one). Where you previously used e_error_run(), you can now do the same thing with e_alert_run_dialog_for_args() (same note about function naming as above). However, my goal is to phase out use of these dialog-related helper functions. The plan is that in the future, instead of reporting errors directly, functions that can fail will take a EAlert** parameter and return a newly allocated EAlert object describing the situation (i.e. the same idiom as GError). The calling function can then determine how to handle or present that to the user. I started changing the files in filter/ to use the design I mentioned in the previous paragraph, so for example, the function: e_filter_element_validate(EFilterElement *element, GtkWindow *parent) became: e_filter_element_validate(EFilterElement *element, EAlert **alert) Other parts of the tree have only been changed to use the equivalent helper functions mentioned above. -- Jonathon Jongsma jonathon.jong...@collabora.co.uk ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
