[Evolution-hackers] UI interaction from book/calendar backends

2012-11-22 Thread Milan Crha
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


Re: [Evolution-hackers] Drop or limit ChangeLog files in tarball releases?

2012-11-22 Thread Matthew Barnes
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


Re: [Evolution-hackers] Drop or limit ChangeLog files in tarball releases?

2012-11-22 Thread Michael Hasselmann
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