Re: [Evolution-hackers] UI interaction from book/calendar backends
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 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. Hi, just a notice that I committed the change to evolution-data-server [1], a new evolution-user-prompter service. It is not used at the moment, except of ./tests/libedataserver/e-user-prompter-test , which shows basic prompts and one extension for Certificate trust prompts, which is an example of an extension for the prompter. It will be used in the backends soon, same as the certificate trust will receive a View Certificate functionality. I wanted to push this rather earlier, to have it part of 3.7.3, and finish other things later. If you run the test you'll see what it can do. If you feel the basic prompts are weird, then please blame Gtk+, it's nothing else than their GtkMessageDialog. All the main code resides in libebackend, check e-user-prompter* files. The -server is for the server part, the -extension is a base struct for any extensions, and the e-user-prompter itself is the client side. I wrote documentation for it too, which, I hope, is written in an understandable way. The certificate trust extension resides in modules/trust-prompt, and its longest part is about dialog itself, the extension has only ~100 sparse lines. Enjoy, Milan [1] git.gnome.org/browse/evolution-data-server/commit/?id=ff581ea9040a44 ___ 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] UI interaction from book/calendar backends
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, especially in quoted replies.) Matt On Mon, 2012-11-26 at 08:37 +0100, Milan Crha wrote: 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. Hi, I was thinking of it, and I feel like it's not correct to initialize gtk within an extension, thus this should be just a new server within eds, with its default implementation using gtk3, which will be accessed through DBus (as you suggested), thus will be replaceable by other implementations. Bye, Milan ___ 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 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] UI interaction from book/calendar backends
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 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. [...] 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 options they have to solve the conflict. However, this dialog is currently unused in evolution-kolab for the reasons you outlined (and the options set per folder without a possibility for the user to decide on a per-incident-basis how to resolve the conflict). Please see the dialog screenshot to get an idea of what would be needed (I've linked to the dialog screenshot to illustrate the use case). Basically this is * an informative text, with some background highlighting * a number of options for the user to choose from (the id of which to be returned to the backend), the conflict resolution strategy in our case (NB: this could be changed for a radio button list and the typical OK/Cancel buttons) * some setting to be applied to the folder configuration (whether to ask again for the next conflict or to keep the current user selection for the folder and not ask again) Maybe this helps ironing out the requirements for a requester infrastructure. Input fields may also be needed in some cases, although PIN entry is already handled (not sure what else would require text input). Kind regards, Christian [0] http://git.gnome.org/browse/evolution-kolab/plain/docs/dialogs/evo-kolab_pim-sync-conflict-dialog.png -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ 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] UI interaction from book/calendar backends
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 options they have to solve the conflict. However, this dialog is currently unused in evolution-kolab for the reasons you outlined (and the options set per folder without a possibility for the user to decide on a per-incident-basis how to resolve the conflict). Hi, I had on mind something simple, especially when you cannot pass pointers over DBus, thus it would be quite complicated to support input widgets in general way. The camel_session_alert_user() function outlines my idea quite well, just provide text to show and then list of buttons which will be available for user choices. I'm not sure if remember this choice in conflict resolution makes sense, because the conflicts can be of different sorts after all. Nonetheless, that can be added as kind of flags, with corresponding value return. Bye, Milan ___ 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] UI interaction from book/calendar backends
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. Hi, I was thinking of it, and I feel like it's not correct to initialize gtk within an extension, thus this should be just a new server within eds, with its default implementation using gtk3, which will be accessed through DBus (as you suggested), thus will be replaceable by other implementations. Bye, Milan ___ 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] UI interaction from book/calendar backends
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 thought the password dialog, even called from gcr, brings in a gtk+ requirement. Good if it's not. 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: ... 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. Sure thing, I like what you suggested. Thanks and bye, Milan ___ 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] UI interaction from book/calendar backends
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 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. Qt is so old-fashioned MeeGo - HTML5 rulez in Tizen! :- Thanks for keeping this in mind. I thing it is just good engineering and will hopefully also turn out to be useful outside of Tizen, which - just to avoid any confusion - does not use EDS at the moment and might never do. I'm bringing it up as an example of a distro where compiling EDS is hard at the moment because of the GTK dependency - there might be other, similiary limited platforms. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
