Re: [Evolution-hackers] UI interaction from book/calendar backends
On Thu, 2012-11-22 at 09:13 +0100, Milan Crha wrote: > What I have on mind is something what Camel already provides [1], the > camel_session_alert_user() function, which basically provides generic > dialog facility for asking users. The question is where to put such > functionality for book/calendar backends, because they are > client-oriented, not session oriented like providers in Camel. It would > not work to teach each client, and also user of the client, about this > interaction, thus I think the right place is evolution-source-registry, > which already requires gtk. This can be hidden on the backend side by > some base class function e_backend_alert_user(), and where it'll pass > the data is up to it. Note this is not used for random errors, for that > is other e_cal/book_backend_notify_error() function, which will be left. Actually I don't think evolution-source-registry requires GTK+. If it's the password dialog you're thinking of, we only link to gcr-base-3 which speaks via D-Bus to the process actually showing the password dialog. I'm not sure if evolution-source-registry is ultimately the right place for user interfaces, but I can't think of a better solution at present. I have a few requests, though: 1) Write this as a ESourceRegistryServer extension, and just link to GTK+ from the extension module. That way it's easily removable if the Tizen folks don't want it, or they want to implement their own version using Qt. 2) Create a new well-known bus name for this. Perhaps something like org.gnome.evolution.dataserver.Prompts 3) Come up with a corresponding D-Bus interface, put the XML spec in the "private" directory and let gdbus-codegen create the GDBus glue. The idea here is to keep the functionality relocatable, both for the benefit of Tizen and for ourselves if we think of a better place for this stuff in the future. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Drop or limit ChangeLog files in tarball releases?
On Thu, 2012-11-22 at 11:45 -0500, Matthew Barnes wrote: > Also, just for the record, the script snippet I'm using to generate the > ChangeLog file comes from https://live.gnome.org/Git/ChangeLog. So ChangeLog already gets auto-generated from git log on make dist, for each release. Why would there then be a need to get rid of it? What's the benefit? If it's only about tarball size, I'd say that's not sufficient enough as an argument. regards, Michael ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Drop or limit ChangeLog files in tarball releases?
On Thu, 2012-11-22 at 08:52 +0100, Milan Crha wrote: > I'm only waiting for an opinion from Matthew, then I'll happily change > the build script. I guess I don't have a strong attachment to it. ChangeLog files are technically part of the GNU Coding Standards [1], and strictly speaking the product we ship is our tarball releases, not our version control system, so there's an argument to be made that we should ship a complete log of changes in our product updates. That said, the GNU Coding Standards were written in an age before distributed version control, and its relevance is debatable nowadays. And I agree 'git log' is more practical for researching change history. We could limit the log to changes since the last major release (3.6.0 currently, then start clean after 3.8.0 ships) to keep the file size under control, but if you'd strongly prefer dropping it entirely then I won't complain. Also, just for the record, the script snippet I'm using to generate the ChangeLog file comes from https://live.gnome.org/Git/ChangeLog. Matt [1] http://www.gnu.org/prep/standards/html_node/Change-Logs.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] UI interaction from book/calendar backends
Hi, the book/calendar backends are currently designed to not have any direct UI interaction with user, they basically serve for data only. While it works, it has its caveats, like when user tries to access server using SSL with self-signed certificate. This should be done like in Camel, where user is asked what to do, instead of, currently implemented, checkbox in account preferences for "Ignore invalid certificates". Another usecase for direct UI interaction is, as xtian suggested some time ago, when synchronizing offline data to the server, with discovered conflicts. There might be found more usecases for sure. What I have on mind is something what Camel already provides [1], the camel_session_alert_user() function, which basically provides generic dialog facility for asking users. The question is where to put such functionality for book/calendar backends, because they are client-oriented, not session oriented like providers in Camel. It would not work to teach each client, and also user of the client, about this interaction, thus I think the right place is evolution-source-registry, which already requires gtk. This can be hidden on the backend side by some base class function e_backend_alert_user(), and where it'll pass the data is up to it. Note this is not used for random errors, for that is other e_cal/book_backend_notify_error() function, which will be left. One related thing, as I mentioned the server certificates and their trust, this should be managed by one central point too - xtian already reads the binary file from multiple processes, which is not optimal - thus I would move the SSL certificate trust database management to the evolution-source-registry as well. Same as it requires place where one can check the SSL database, and possibly take back his/her previous reject/accept, but there is none in evolution at the moment, as far as I know. What would people think about these two things? Bye, Milan [1] http://git.gnome.org/browse/evolution-data-server/tree/camel/camel-session.c#n1275 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers