On Thu, 2012-11-22 at 09:13 +0100, Milan Crha wrote:
> 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 ce
Yes, the gtk_init() issue occurred to me after posting that suggestion. I
agree a separate process is the better idea. Then gtk3 won't taint
evolution-source-registry.
(Apologies for top-posting. I'm trying out Dan's webkit-composer branch and it
seems to have some kinks yet to be worked out
On Mon, 2012-11-26 at 10:08 +0100, Christian Hilberg wrote:
> Thanks Milan for bringing that up again. Yes, some infrastructure to
> request for user input from within the backends would be very helpful.
> We have a dialog ready [0] in evolution-kolab to ask for a user selection
> from several opti
Hi everyone,
Am Donnerstag 22 November 2012, um 09:13:16 schrieb 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 s
On Thu, 2012-11-22 at 13:04 -0500, Matthew Barnes wrote:
> 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.
On Thu, 2012-11-22 at 13:04 -0500, Matthew Barnes wrote:
> 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
On Thu, 2012-11-22 at 13:04 -0500, Matthew Barnes wrote:
> 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.
Hi,
yes, I
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/calenda
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,
whe
