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

[Matthew Barnes <mbarnes redhat com>]

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