[Evolution-hackers] [heads-up] evolution-data-server is libsoup3 now
Hello, just a quick heads-up, the evolution-data-server development version is libsoup3 now; it will be the 3.45.1 release. The port depends on libsoup3 change [1], which improves libsoup3 use in multi-threaded applications. Most people are probably aware, all apps using the evolution-data- server directly or indirectly need to use libsoup3 as well, the same their dependencies, because libsoup2 and libsoup3 cannot be loaded into the same process at the same time (doing so aborts the application with an appropriate message). One thing, the libgdata has a pending merge request for the port to the libsoup3, but it needs more testing and such. Use -DENABLE_GOOGLE=OFF CMake option until it's sorted out. The option disables the Google tasks support only. I may extract necessary bits out of the libgdata to not depend on libgdata at all, but no promises whether I'll make it on time for the 3.45.1. See [2] for some insights. Of course, Evolution itself and evolution-ews will be ported to the libsoup3 at the same time. Bye, Milan [1] https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/283 [2] https://discourse.gnome.org/t/giving-up-maintainership-of-libgdata/9983 ___ 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] Adjusting email for display
On Thu, 2022-06-16 at 04:13 +0200, Ángel wrote: > Apparently this would mean changing the email contents before they > are passed to WebkitGtk for display (alternatively, they could be > changed when fetched from the mail store). Hi, why in the mail store? That means you cannot restore the message to its original form, which is kinda bad, is it not? Nonetheless, the mail providers are not extensible, thus you cannot get to the internal interpretation of the email and modify it in their store/cache. > but not the place where it defines the "mail://" protocol so that > webkit may us such URI to fech a html document. It's defined here: https://gitlab.gnome.org/GNOME/evolution/-/blob/master/src/mail/e-mail-request.c but all the work is done here: https://gitlab.gnome.org/GNOME/evolution/-/tree/master/src/em-format split into parser, which "filters" which parts should be shown, and then into formatter, which converts the selected parts' content into HTML, which is passed into the WebKitGTK. You can write your own extension and override default handling for either of the content types. When you run Evolution from a terminal as: $ CAMEL_DEBUG=emformat evolution You'll see some information, which may or may not be useful for you. An example is here: https://gitlab.gnome.org/GNOME/evolution-rss/-/blob/master/src/e-mail-formatter-evolution-rss.c https://gitlab.gnome.org/GNOME/evolution-rss/-/blob/master/src/e-mail-parser-evolution-rss.c even it defines its own part with its own Content-Type: https://gitlab.gnome.org/GNOME/evolution-rss/-/blob/master/src/e-mail-part-rss.c thus it's not the same thing as you want. The extensions are described in a bit more detail here: https://wiki.gnome.org/Apps/Evolution/Extensions with an example module, which does something else, but it can be used as a starting point. If you want to cover only message preview, then maybe a bit easier would be to use the preview plugin: https://wiki.gnome.org/Apps/Evolution/Extensions#Preview_and_WebKit_Editor_plugins This won't cover reply/forward of the message, for those you'd need also an editor plugin and even that won't help if the user forwards as attachment. The forward as attachment won't cover the em-format either, but it covers the reply/forward "inline". 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] Forward with Template, like there is already a Reply with Template
On Tue, 2022-06-14 at 10:12 +0200, Ronnie Garcia via evolution-hackers wrote: > I'm new to this list, and using Evolution for 3 years now. Thanks for > the great product ! Hi, the evolution-hackers is for coding questions/discussions, the user- oriented queries are better discussed on the evolution-list. > That would set the right headers and prefix the subject line with > "Fwd:" The only internal difference between forward and reply is an In-Reply-To header, which is useless for the recipient, unless he/she gets also the original message. The other difference is the body format, but that thing you can control in the template, together with the subject and the recipients. What I mean is that despite the option is called "Reply with Template", it's easy to use it for forwards as well. 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] How do I use S-Expressions on Evolution Data Server’s ECal API?
On Wed, 2022-03-09 at 02:36 +0100, cont...@ultrasonicmadness.org wrote: > I think the 'occur-in-time-range' command might be relevant to what > I’m trying to do, but I’m not sure what isodate_from_time_t is doing > or how the return value from it is formatted. Is there documentation > on this or a list of commands that I’m missing? Hi, you are right, there is not much information about the way constructing the S-Expressions in the Evolution(-data-server). The easiest is to search the existing code and check what it does, just as you did. The `occur-in-time-range` is what you want, as you figured. The list of possible expressions is here: https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/gnome-41/src/calendar/libedata-cal/e-cal-backend-sexp.c#L1311 when you search for the respective functions in that list, they contain a comment about their syntax. There are some common symbols defined here: https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/gnome-41/src/libedataserver/e-sexp.c#L1476 with a little bit information about builtin common s-expressions: https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/gnome-41/src/libedataserver/e-sexp.c#L21 With respect of the isodate_from_time_t(), the easiest is to just call that function (you did not say what programming language you use, though using introspection you should have this function available too). It's defined here: https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/gnome-41/src/calendar/libecal/e-cal-time-util.c#L631 Quick examples: To get list of events occurring between 2022-02-27 and 2022-04-10 for Europe/Prague timezone you use this S-Expression: (occur-in-time-range? (make-time "20220227T23Z") (make-time "20220410T00Z") "Europe/Prague") To get events, which occur in the same time range as above and contain word "orange" in the Summary you use: (and (occur-in-time-range? (make-time "20220227T23Z") (make-time "20220410T00Z") "Europe/Prague") (contains? "summary" "orange")) To get events, which occur in the same time range as above and not contain word "bad" in the Summary you use: (and (occur-in-time-range? (make-time "20220227T23Z") (make-time "20220410T00Z") "Europe/Prague") (not (contains? "summary" "bad"))) You can get more complicated expressions. If you want to debug it any further, then I suggest to place a breakpoint into cal_data_model_update_full_filter() and see what `filter` it constructs there: https://gitlab.gnome.org/GNOME/evolution/-/blob/gnome-41/src/calendar/gui/e-cal-data-model.c#L805 You can create quite complicated expressing with the Evolution GUI. Hope it helps. 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] evolution-persist: background notification extension module for Evolution
On Sun, 2022-02-06 at 22:59 +0800, Hu Jialun wrote: > My intention was actually to maybe first gather some feedback from > the more programming-inclined Evolution developer community, since > the extension is still rather immature and it is unlikely that an > average user would feel happy fiddling with something at such an > early stage. Hi, I see. Feel free to "announce" the module on the evolution-list, there might be people willing to test it, I guess. The best if you provide a pre-built code, of course, because not everybody is able to compile it on its own (that's basically what you said, I agree with you). 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] evolution-persist: background notification extension module for Evolution
On Fri, 2022-02-04 at 01:04 +0800, Hu Jialun wrote: > I have just put together an Evolution extension to keep evolution > running in the background after all windows are closed Hi, good job. I know people sometimes look for a similar plugin and claim the alternatives do not work these days. > ... or through the mailing list. Ehm, do you mean this mailing list? I do not think anybody here is going to fix bugs in any third-party software. It's a bad idea to "hijack" mailing list used for the core Evolution projects development (count in evolution-data-server, evolution, evolution-ews and evolution-mapi), everything else is considered third-party and should use its own bug tracker and other communication channels. Look on it as with the evolution-on you mentioned. It's not tight to this mailing list at all and it should not be. You can subscribe to the evolution-list instead, which is meant for the users, and check messages there, in case the users would claim any problem with your plugin, but asking them to use either of these two mailing lists is not a good idea. The first answer to their claims would be: use bug tracker of your 3rd-party plugin, because it's not an official plugin and it is not maintained by the upstream/Evolution team. 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] Issues during building evolution from source
On Wed, 2021-11-10 at 21:23 +0100, pa...@bogdan.edu.pl wrote: > error: Package `GObject-2.0' not found in specified Vala API > directories or GObject-Introspection GIR directories > error: Package `Gio-2.0' not found in specified Vala API directories > or GObject-Introspection GIR directories > error: Package `libxml2-2.0' not found in specified Vala API > directories or GObject-Introspection GIR directories Hi, updating Vala does not help. Those errors say, and mean, that there are missing three packages from the GObject Introspection world. It's similar as the -dev packages. Rather than searching where they come from in the Ubuntu, supposing you want to build the evolution-data- server only for the Evolution (which does not use the Vala at all), I suggest you disable Vala and GOject Introspection build. That can be done with the cmake command, when you change the below options: -DENABLE_INTROSPECTION=OFF -DENABLE_VALA_BINDINGS=OFF You can also -DENABLE_INSTALLED_TESTS=OFF , if you want to (you are probably not going to run those tests, thus no need to install them). I suggest to delete the _build directory and start the build from scratch, to make sure the new options are properly propagated into the build scripts. 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] Issues during building evolution from source
On Tue, 2021-11-09 at 10:38 +0100, Paweł @ Bogdan wrote: > I'm trying to build evolution from sources. Hi, I do not know whether you are aware, but there is a wiki page about the build of it, with a lot of useful information: https://wiki.gnome.org/Apps/Evolution/Building You do not need to stick to it, it's only one way, which works. 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] Windows port of evolution
On Sat, 2021-11-06 at 20:45 +0100, pa...@bogdan.edu.pl wrote: > I'm new guy here. I think Evolution is the best e-mail client. However, > I use Windows. I run Evolution in WSL. This is not as comfortable as > I'd like it to be. > > I'm software developer and I'd be happy to work on the compilation for > windows. But I'd like to know if it is even possible. Hi, once upon a time, there was a working build, as can be seen here: https://gitlab.gnome.org/GNOME/evolution/-/tree/master/win32 See the readme.txt file there. 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] Using EDS backend for other remote providers
On Fri, 2020-12-18 at 22:41 +0100, Juozas Miškinis wrote: > I'm curious if it's at all possible to use the provided API for new > online providers, e.g. Todoist, without directly messing with EDS > source code. Hi, a new provider means writing a new backend, thus "messing" with EDS. You can write the backend as a 3rd-party module, just like for example evolution-etesync, evolution-ews and some others are. 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] Build configuration extension for data service components
On Wed, 2020-11-25 at 16:06 +0100, Markus Elfring via evolution-hackers wrote: > Extend build configuration for libraries from the GNOME Evolution > data service > https://gitlab.gnome.org/GNOME/evolution/-/merge_requests/72 Hi, you can safely avoid duplication/ping on this list, when you fill a merge request in the GitLab instance. That can save you time and bandwidth (and time) to others. By the way, it's evolution-data-server, not evolution-data-service. 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] Checking installation of header files for data service components
Hi, On Mon, 2020-11-23 at 21:00 +0100, Markus Elfring via evolution-hackers wrote: > This build parameter can trigger also further development challenges. No, as long as you use it properly. Evolution depends on the evolution-data-server, not only as a usual library dependency, but also because things are just split into the two projects and to fix a problem in Evolution can mean to touch the evolution-data-server code, sometimes only there, sometimes on both places. Thus when you develop for Evolution, you should build it into the same CMAKE_INSTALL_PREFIX as you built the evolution-data-server with. That's all. It seems it's not understandable from the copy tutorial of "how to build from sources" for you for some reason, from a link I gave you I guess like tenth times: https://wiki.gnome.org/Apps/Evolution/Building Read it carefully. Follow it closely. Things will work. I said it to you elsewhere already: if you do nasty things (using the DESTDIR and expect that you can build against such "copied" (they are not *installed*, because DESTDIR != CMAKE_INSTALL_PREFIX) sources, then you are in it on your own. It doesn't mean the code base doesn't support other environments, it only means that there is no intention to make the Building page too complicated, to rise the barrier to the newcomers, from my point of view unnecessary. You do not seem to be a newbie, you seem to be able to make things work on your own, with your nasty workarounds. Which is good. For you. 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] Checking installation of header files for data service components
On Mon, 2020-11-23 at 17:15 +0100, Markus Elfring via evolution-hackers wrote: > How do you think about to take further software extension > possibilities into account here? Hi, no, I'm sorry. Instead, use DESTDIR properly (aka not at all, because you are not a packager, you are not building a package) and configure the project properly, by using expected CMAKE_INSTALL_PREFIX, not some artificial. That's at least my understanding from this lengthy thread. 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] Checking installation of header files for data service components
On Mon, 2020-11-16 at 15:45 +0100, Markus Elfring via evolution-hackers wrote: > It seems that this is not directly supported so far with the provided > version. Hi, no, no, no, I do not think so. When you tell the software that the files will be located in /a/b (in this case by using -DCMAKE_INSTALL_PREFIX=/a/b) and then you install it into /g/h (by using DESTDIR=/g/h make install) then it does exactly what you told it. Use -DCMAKE_INSTALL_PREFIX=/g/h and: a) you'll install files where you want them to be installed b) you do not need to (mis-)use DESTDIR at all. If you are going to object that you intentionally want to use different install directory in configure and then install files elsewhere and then you intentionally want to use the files from the other location than for which the software was configured, then you did not understand what the DESTDIR is for. Or I did not understand it, but, from my point of view, the [1] (for which I gave a link to earlier) tells its intention very clearly. I consider this "discussion" over. Thanks and bye, Milan [1] https://www.gnu.org/prep/standards/html_node/DESTDIR.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] Checking installation of header files for data service components
On Mon, 2020-11-16 at 14:52 +0100, Markus Elfring via evolution-hackers wrote: > I noticed specific limitations. Hi, I did not notice any limitation. > I would like to reuse software components directly from a “staged” > (test) installation. Sure, then do configure it as such. 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] Checking installation of header files for data service components
On Fri, 2020-11-13 at 22:03 +0100, Markus Elfring via evolution-hackers wrote: > > Make sure you provide precise commands to reproduce the problem. > > The provided build data show helpful information for the failure > to include a special header file. Hi, pity you denied to do the above. > (with the help of the environment variable “DESTDIR”). Oh, here's a little tiny bit of requested information. Please, read this: https://www.gnu.org/prep/standards/html_node/DESTDIR.html and think what you've done wrong. Hint: You misuse the DESTDIR variable. Hence, there's nothing to be changed in the build process. I mean, on the project side. It works perfectly fine and as expected by the rest of the world. There are things to be changed on your side, though. 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] Checking storage location for the module “alarm-notify”
Hi, On Wed, 2020-11-11 at 15:56 +0100, Markus Elfring via evolution-hackers wrote: > I imagined then that the module “alarm-notify” could be offered as > auxiliary for the service implementation. So it is, no? 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] Checking storage location for the module “alarm-notify”
On Wed, 2020-11-11 at 14:35 +0100, Markus Elfring via evolution-hackers wrote: > > There are reasons why it's where it is. > > Can they be reconsidered occasionally? Hi, those are reasons, not opinions. They cannot be reconsidered. To be more specific, the module lives in Evolution, because: - it's Evolution's extension of the data server's code - it uses Evolution's code - it uses Evolution's data (settings) - it is specific to Evolution, it doesn't know about other software, it knows only about Evolution Hence it is at the right place. > I dared to ask directly. Oh, in that case the problem is on my side, I (probably) misread your query. I'm sorry about that. 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] Checking storage location for the module “alarm-notify”
On Wed, 2020-11-11 at 13:17 +0100, Markus Elfring via evolution-hackers wrote: > I propose to clarify further software development ideas according to > this commit: Hi, the thing is that it's unclear what those "ideas" are. You forgot to introduce what you are talking about and what you want to achieve. Or, at least for me, it wasn't clear from your vague text. Let me guess: * the "alarm-notify" module is the one in Evolution, right? It's not said anywhere. That you reference a commit doesn't mean everybody will thoroughly read it to figure out what you really want. * you are questioninig the place of the module, right? In what way? You didn't say it, did you? Are you "suggesting" to move it to the evolution-data-server? Or to a separate place? Or? My opinion is: do not move it anywhere. There are reasons why it's where it is. Being there a chance to have it for example in eds, it's there from the very beginning. * if there were any other magics hidden under the generic terms you provided, I didn't get them even more than that what I guessed from it above. Do you see the very difference in the communication? Being straight and concrete. I'd like to ask whether it's possible to move the Evolution's "alarm-notify" module to <>, because <>. Fill the gaps... 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] Checking storage location for the module “alarm-notify”
On Wed, 2020-11-11 at 09:50 +0100, Markus Elfring via evolution-hackers wrote: > The component is still stored in a repository which belongs to a > client program instead of the mentioned data service implementation. > > How do you think about to manage this module as a companion component > in the service repository? Hi, please, use gitlab tickets for any such requests. It's much easier to deal with them than with messages in the mailing list, which can get lost easily. Before you fill a new ticket, could you rephrase what you are asking for, please? I'm not sure I understand what you mean when you *only* use vague generic terms instead of being specific and concrete. Remember, being clear helps; being vague does not help. 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] Checking application of extensions and plugins for a software test installation
On Mon, 2020-11-09 at 11:30 +0100, Markus Elfring via evolution-hackers wrote: > How do you think about to reduce any remaining messages? Hi, those you pasted are printed by evolution (and evolution-alarm-notify), but they are not evolution-related issues. The gtk.css is due either your theme or your customizations. For the g_application_run() is filled a bug against glib, and the Session.Manager is because gtk+ is trying to call a method your Xfce D-Bus interface doesn't contain. 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] Checking application of extensions and plugins for a software test installation
On Mon, 2020-11-09 at 10:24 +0100, Markus Elfring wrote: > Should any failures for the loading and integration of desirable > modules/plugins trigger corresponding clear warnings (or error > messages)? Hi, you quoted the answer for this question in your own message. I miss a point of asking it, I'm sorry. Bye, Milan P.S.: It would be helpful if you Reply To List here, not Reply to All. It works better here, at least for me. Thank you in advance. ___ 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] Checking application of extensions and plugins for a software test installation
On Sat, 2020-11-07 at 14:10 +0100, Markus Elfring wrote:
> (evolution:15206): evolution-util-WARNING **: 13:38:25.276: Failed to
> call 'Evo.AddRuleIntoStyleSheet("*","-e-web-view-style-sheet",".-e-
> web-view-background-color","background-color: #fcfcfc;")' function:
> WebKitJavascriptError:699: undefined:1:4: ReferenceError: Can't find
> variable: Evo
Hi,
this looks like you install (by DESTDIR?) the Evolution files into a
directory, which is not the one you told Evolution they will be
(CMAKE_INSTALL_PREFIX). Just a guess.
> But I do not see an error message which I would interpret as a direct
> explanation for the missed display of the menu entry “Plugin
> Manager”.
Aha, I see, Evolution doesn't know what modules/plugins should be
loaded, thus it doesn't claim any error about them "missing". See above
for the probable reason.
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] Checking application of extensions and plugins for a software test installation
On Tue, 2020-11-03 at 12:19 +0100, Markus Elfring wrote: > By the way: > I installed the software package “libwebkit2gtk-4_0-37” (2.30.2-1.1) > yesterday afternoon. > Now I stumble also on the following error message. > > home/elfring/Projekte/Bau/Evolution/3.36.5/Probe/bin/evolution: > symbol lookup error: /usr/lib64/libwebkit2gtk-4.0.so.37: undefined > symbol: wpe_fdo_initialize_shm Hi, I've not much idea on this one. On the first look, it looks like a mismatch of the development files and the binary files, or stale build artifacts (then you might eventually rebuild), or some dependency (possibly of the WebKitGTK) is old/new, or... You may ask Google or your distribution maintainer, though the quickest workaround is obvious, revert the package(s) update. > git checkout 3.36.5 Why do you use obsolete version? If you are going to propose patches, then you should follow the main development branch, which is called 'master' here. That will also make sure your patches will apply cleanly to the development version. > > Maybe Evolution claims runtime warnings on the console, > > Some were displayed. Aha, then focus on those and do fix them first. The runtime warnings are meant to claim when something unexpected happens. Like the one with the undefined symbol above. I suppose until you fix that one you cannot run your custom build at all. > > If you have issues, then try the Building wiki page,... > > Who would like to help with mentioned program start arguments > and related dependencies? Funny you quoted the answer too. That only supports what Andre said. That's really sad. I'm done with this thread. Do not expect additional answers from me. Thanks for trying 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] Checking application of extensions and plugins for a software test installation
On Tue, 2020-11-03 at 11:00 +0100, Markus Elfring via evolution-hackers wrote: > Did you notice the program start parameters with which I started > the clarification attempt here? Hi, to be honest, I did not notice any "program start parameters" you are mentioning now, to be in the original post of this thread. More importantly, you did not tell us *how* you build the Evolution. You use CMake, of course, but that's far from the answer for the *how*. Anyway, the Edit->Plugin Manager is added as an evolution-plugin-manager.so module. Maybe Evolution claims runtime warnings on the console, or it doesn't load any module (if that's true - you didn't tell us - then you may see an empty Evolution window. I mean really empty, no Mail, no Contacts, no Calendar, ... just a gray (depending on your theme) empty window), because Evolution cannot read its plugins/modules or the libraries they want (it depends whether there's a runtime warning hinting any such thing on the terminal of the Evolution or not - you did not tell us). Why is that so is the question. It can be that your CMAKE_INSTALL_DIR doesn't match the place you install the files to (due to the DESTDIR usage?). Do fix that and the things will work. From my point of view, you misunderstand and misuse the DESTDIR variable. But I can be wrong, in either or both statements. Again, anybody else using the DESTDIR uses it successfully, only you have problem with it. But really, follow the Building wiki page, from the top to the bottom, and you'll get things working easily. If you are doing some magics nobody has an idea of, then you are in it on your own. I'm sorry. Note this is not about alternative build ways, you can build the software the way it works the best for you. If you have issues, then try the Building wiki page, check what you've done differently and try to find out what you do wrong, because you surely do something wrong. I mentioned it elsewhere, Evolution is a complex application. Do pick a simpler application, with which you can get familiar with some basics and advanced practices. Just my opinion. 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] Checking application of extensions and plugins for a software test installation
On Mon, 2020-11-02 at 21:42 +0100, Markus Elfring wrote: > > To get some background information to the archive readers (which I > > learnt from the GNOME's GitLab ticket(s) you filled): you've been > > building only Evolution > > I built a selected version of this program. Hi, okay, I take it as "yes". That was probably before I pointer you to the Building wiki page. I do not know. > > against system evolution-data-server (eds) and you do not like > > that Evolution installs its eds module into the directory, > > where eds expects to have the modules installed. > > I suggest to recheck the functionality from the CMake scripts. > > elfring@Sonne:~> /usr/bin/pkgconf --variable=uimoduledir > libedataserverui-1.2 > /usr/lib64/evolution-data-server/ui-modules I do not see a need for it. This only supports what I wrote in my previous mail and I wrote it because you wrote the same thing in one of your GitLab tickets. > This environment variable has got a known purpose. Sure, and distributions use that as such. Successfully. It also worked here, when I tried it. Successfully. Maybe I didn't get your claim then. > > My approach for a test installation is clearly described, isn't it? Well, you did not describe anything from your build process. I mean from how exactly you are trying to build Evolution. All I wrote here was a plain guess on some random pieces of the information I collected from various places, some of which I noticed only accidentally. In any case, to make life easier to the contributors, the following wiki page had been provided years ago: https://wiki.gnome.org/Apps/Evolution/Building It can have its caveats, the distributions changed meanwhile, thus it can be a "fun" to install all the dependencies, but the core parts are working when the steps are followed precisely. I know that. I'm not able to provide support for building such complex application as Evolution is to every single person whom may eventually want to start coding in such a beast, the less when it doesn't follow an article which had been provided for that (to make life easier) very purpose. Again, Evolution is a complex application. If the dependencies are not complete or any other problem arises, then it's expected that the person whom wants to contribute to such complex application is able to solve such trivial thing as installing necessary dependencies, about which the build process claims. 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] Checking application of extensions and plugins for a software test installation
On Mon, 2020-11-02 at 20:44 +0100, Markus Elfring via evolution-hackers wrote: > > > > Wanting advanced techniques means being an advanced person, > > I suggest to adjust possible target conflicts. Hi, target conflicts? The page is for newcomers, as had been said. There is no target conflict. Stay focused on the context, which is the wiki page. > > which is against being nice to newcomers, because too many choices > > can confuse people and make it too easy to make mistakes. > > Some automation and continuous integration can help to improve > the build process considerably, can't it? With the wiki page about the steps how to build Evolution from the sources? That would be surely interesting. > > We are discussing dependencies and development consequences for > two known variables, aren't we? > > > > In any case, no DESTDIR into the Wiki page, no. Keep it simple, > > please. > > Will this technical detail become more interesting also for CMake > scripts? No and no. To get some background information to the archive readers (which I learnt from the GNOME's GitLab ticket(s) you filled): you've been building only Evolution (thus not following the Building wiki page from its top) against system evolution-data-server (eds) and you do not like that Evolution installs its eds module into the directory, where eds expects to have the modules installed. The DESTDIR thing would just make the contributors confused why their eds module change has no effect. By the way, $ DESTDIR=/tmp/evo/ make install does install the module-evolution-alarm-notify.so under the /tmp/evo/, not under the CMAKE_INSTALL_PREFIX I used to configure the project, thus the usage of the DESTDIR works properly for me. I do not know what (else?) you've done differently that the things do not work for you, or why you think they don't work properly for you. I hope this thread is resolved now. 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] Checking application of extensions and plugins for a software test installation
Hi, On Mon, 2020-11-02 at 18:14 +0100, Markus Elfring via evolution-hackers wrote: > > If you do not want to follow that wiki, then, I believe, it doesn't > > make sense to request updates of it. > > I got further software development ideas. My 'it' in the above quoted text was meant as 'the wiki page'. I'm glad you want to propose patches. > I am looking for better support of advanced software build techniques > so that more tasks can eventually be automated in helpful ways. Wanting advanced techniques means being an advanced person, which is against being nice to newcomers, because too many choices can confuse people and make it too easy to make mistakes. > > By the way, `DESTDIR=Test make install`, though I do not understand > > why you'd want to change the CMAKE_INSTALL_PREFIX during the build > > at all. > > I suggest to take another look at available information sources. > > Example: > https://cmake.org/cmake/help/v3.19/variable/CMAKE_INSTALL_PREFIX.html > > * The support for the environment variable “DESTDIR” is limited. > > * It might occasionally be safer to express the intention also > by a corresponding CMake variable. I'm not sure I read it properly. It sounds to me that your first sentence says my quoted text can be extended, then the rest says the opposite, that it supports what I wrote. In any case, no DESTDIR into the Wiki page, no. Keep it simple, please. 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] Checking application of extensions and plugins for a software test installation
On Mon, 2020-11-02 at 17:32 +0100, Markus Elfring wrote: > Do you use a command like “DESTDIR=Test cmake --install > build_directory” for this purpose? Hi, I use what is written on the wiki page. I guess I mentioned that in my previous mail. If you do not want to follow that wiki, then, I believe, it doesn't make sense to request updates of it. It's meant to make things easier for the newcomers. Adding anything like DESTDIR feels too complicated for anyone not touching build tools every day. If you follow the Wiki page by copy of the commands (+/- adding dependencies which your distro may or may not have preinstalled), you get the build working quite quickly. By the way, `DESTDIR=Test make install`, though I do not understand why you'd want to change the CMAKE_INSTALL_PREFIX during the build at all. Bye, Milan P.S.: Reply To List (Ctrl+L in Evolution) works better for me on this list than Reply To All. ___ 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] Code updates for MS 365
On Mon, 2020-11-02 at 11:21 -0500, Phillip A. Kenyon via evolution- hackers wrote: > Has anyone looked into updating the Evolution code to support that? Hi, there exists some code within evolution-ews (3.38.x), which can use the Microsoft Graph API, but that API is highly incomplete and basically unusable for such clients like Evolution. I can name you most of the problems I had with that Microsoft Graph API, but I do not want to spam the list. I do not know when you've read the OAuth2 page the last time. There had been done some changes recently. Maybe check it out again: https://wiki.gnome.org/Apps/Evolution/EWS/OAuth2 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] Checking application of extensions and plugins for a software test installation
On Mon, 2020-11-02 at 15:22 +0100, Markus Elfring wrote: > > Would you like to continue the clarification for the topic > “Improve descriptions for software build dependencies”? > https://gitlab.gnome.org/GNOME/evolution/-/issues/1198 Hi, it's a Wiki page. Basically anyone can improve it. It's definitely not improved by opening bug reports. > Do you try the software out also with extra test installations? I do not know what you mean. Nonetheless, I guess I do. That page had been created with the steps I use every single day, +/- every single day. Thus yes, I do. > Is the dialogue “Plugin Manager” available there? Yes. Or, where there? In the sources? Yes, of course it is. 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] Checking application of extensions and plugins for a software test installation
On Mon, 2020-11-02 at 11:22 +0100, Markus Elfring via evolution-hackers wrote: > Which variables and settings should be adjusted accordingly? Hi, you may want to consult: https://wiki.gnome.org/Apps/Evolution/Building 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] Issue Building Flatpak version
On Sat, 2020-08-08 at 17:42 -0500, Japhering, Anonymous via evolution- hackers wrote: > flatpak --user remote-add --no-gpg-verify --if-not-exists > evolution-repo localrepo > > All of which, appear to function and produce the expected results. > > However, when I get down to .. > > flatpak --user update org.gnome.Evolution-stable Hi, the application is called org.gnome.Evolution, not org.gnome.Evolution-stable. Try: flatpak list > and if I try > > flatpak --user install org.gnome.Evolution-stable The command is incomplete, read the wiki page carefully. I had never a problem when I used copy of the commands from that wiki you referenced. Try: flatpak remotes By the way, if you use "continuous" update of your flatpak build, and if you did it before Martin changes (whom renamed the repos and other things), then it's possible your repo names do not match. You can check the old versions/diffs here: https://wiki.gnome.org/action/info/Apps/Evolution/Flatpak?action=info Hope it helps, 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] [PATCH] fix issue #895: "Time" portion of calendar entries not scaling with font
On Sat, 2020-07-25 at 10:09 +0200, Stefan Paul Noack wrote: > - fix clipping rectangle height: > was hard-coded to 14 before, now row_height is used > > - (flat drawing style) fix clipping rectangle width: > text could be drawn outside the event rectangle, now clips > correctly > > - (rounded drawing style) scale the background pattern that separates > the time portion from the body of the event: > calculation was broken, new method produces the same result > for > 96 DPI, but also works for larger values Hi, thanks for the patch. You do not need to resend it on multiple places, attaching it to the bug [1], which you did, is sufficient. It's even better track there, than here on the mailing list. Of course, it's easier to be noticed when it's a merge request, but I agree creating a merge requests adds some burden, which is not needed for simpler changes. Let's continue in the bug [1]. Bye, Milan [1] https://gitlab.gnome.org/GNOME/evolution/-/issues/895 ___ 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] Shedding some light on evolution-data-server's #ESourceRegistryWatcher
On Sun, 2020-04-19 at 14:20 +0200, Juozas Miškinis wrote:
> Hey everyone!
>
> I've been having some trouble trying to capture the "add/remove task
> list" events in evolution-data-server and I was hoping that you could
> perhaps clear some things up for me.
>
> 1) Here's a barebone #ESourceRegistryWatcher implementation in gjs
> (returns no errors) which DOESN'T WORK (i.e. _onAppeared and
> _onDisappeared methods aren't executed upon task list
> addition/removal): https://paste.gnome.org/pboxc98jo
> 2) Here's a similar WORKING approach that combines
> #ESourceRegistryWatcher and ESourceRegistry::source-added signal
> (which captures all types of #ESources):
> https://paste.gnome.org/phr0crkit
>
> The reason to combine them here is not clear to me, but without the
> watcher (i.e. if I removed line 27 in
> https://paste.gnome.org/phr0crkit), registry.connect('source-
> added'...) wouldn't work either.
>
> Here's my main question: is there anything obviously wrong with what
> I have in #1?
Hi,
I'm sorry I cannot help more, I do not speak gjs-ish, especially how it
works with respect of asynchronous calls, but I have few guesses, like
I'd rather use synchronous calls and make sure the variables you
assigned the instances to are not vanished during garbage collection.
Again, I do not know how gjs works and what it does with the GObject
introspection generated code.
I know that the ESourceRegistryWatcher works properly, it is used by
evolution-alarm-notify and some other parts of Evolution itself.
I'd also try to use C, to see whether it'll work, which may prove the
problem in the gjs code/usage, not in evolution-data-server itself.
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] A probelm with evolution software 3.28.5-0ubuntu0.18.04.1
On Wed, 2019-12-04 at 15:16 +0100, Régis Ramel wrote: > Since I updated my computer from ubuntu 16.04 to ubuntu 18.04 and so > updated the software evolution Hi, this looks like an evolution-list question, rather than evolution-hackers. Also note, please, that 3.28.5 is very old, the current upstream supported version series is 3.34.x. > Appointments displayed on the monthly view of the calendar doesn't > mention the appointments of the current day. So when you look at > eleven in the morning for example, you don't see the appointments in > the afternoon of the current day. You see only appointments beginning > the day after. As long as you've there enough space (the month view is very limited in this regard), then I'd say there is something odd with your time zone. Or with the timezone conversion between your timezone in Edit->Preferences->Calendars and Tasks, and the timezone the respective events are in. When you open for example the Day view, do the events show properly there, at a correct time? Being it about time zones, I'd be afraid that the issue might not be only in evolution or evolution-data-server, but also in libical or tzdata. I cannot tell for sure (see below). > It's a regression which is really uncomfortable. > > It would be great if you could fix this problem. It's likely that the current stable version has that fixed. If you can give it a try somehow, then it'll be appreciated. As I did not notice this with 3.34.x, I'd guess it is fixed, but more detailed information is needed to know for sure. The worst case scenario (for you) would be that the current version has it fixed, in that case you might need to ask your distribution maintainer to backport relevant patches, because the upstream doesn't package for all distributions out there, it's done by respective distribution maintainers. 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] Upcoming evolution-data-server API changes (libical-glib + more)
On Sat, 2019-09-14 at 22:23 +0530, Victor Jonathon Calel via evolution- hackers wrote: > https://bazaar.launchpad.net/~victor-jon/indicator-datetime/drop-phone-code/view/head:/src/planner-eds.c > > (It's bzr though. I can move into git if required.) Hi, no need for git, I only didn't work with bazaar yet, thus if you have a command to download/checkout the branch, which I'd be able to configure (using CMake, if I read it correctly) and build, then I can help you with the port. 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] [PGP] decrypt into local folder
On Tue, 2019-07-09 at 12:25 +0200, J T via evolution-hackers wrote: > I encrypt almost all my emails with PGP. This has several significant > drawbacks: > 1. Since I generate new private key every year, I need to keep track > of all of them to be able to decrypt and look at my old emails. I > don't like this. I want to archive old keys only for emergency > purposes and have clean PGP keyring. > 2. It is impossible to do searches over encrypted emails. > > I think it would be nice to have option or message-filter 'Decrypt > into (local) folder', where emails are kept decrypted. Hi, you can propose new feature requests at: https://gitlab.gnome.org/GNOME/evolution/issues/new though for the 1) I'm not sure how the UI would be done. A similar option to "Send encrypted, but store decrypted in the Sent folder" would make similar job, as both scenarios void the encryption purpose. For the 2), there already exists an old report here: https://bugzilla.gnome.org/show_bug.cgi?id=648774 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] hang when attaching images (3.32.1-2)
On Tue, 2019-05-28 at 18:08 +0200, Lukas Pirl wrote: > Thanks for taking care, Andre. This is what I see for Evolution > 3.32.2-1 (where the problem persists). Hi, it shows [1] that you do not have installed debuginfo packages for whole evolution (and other related libraries), thus the backtrace is not that useful as it could be. Nonetheless, it shows that evolution is waiting for the gnome_desktop_thumbnail_factory_generate_thumbnail() to finish, which comes from /usr/lib/x86_64-linux-gnu/libgnome-desktop- 3.so.17. Whether the problem is in this library or in the program it calls to generate the thumbnail (which can eventually be specific to your settings) I do not know and cannot guess. > Is discussing traces actually better suited for evolution-list@…? If > you think so, feel free to reply vie evolution-list@…. There's a bug tracker to discuss issues, it's much better than mailing lists. It's okay to start discussion on a mailing list, because sometimes the issues are known or unrelated to evolution itself. I mean, there's no problem to start initial investigation on the mailing list and turn it into a bug report later. Bye, Milan [1] For the reference and easier searching, as the pastebin can expire: Thread 1 (Thread 0x7fa98bc4c200 (LWP 28763)): #0 0x7fa994fae037 in select () at /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fa997f05230 in g_spawn_sync () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fa9901fa2cb in gnome_desktop_thumbnail_script_exec () at /usr/lib/x86_64-linux-gnu/libgnome-desktop-3.so.17 #3 0x7fa9901e088e in gnome_desktop_thumbnail_factory_generate_thumbnail () at /usr/lib/x86_64-linux-gnu/libgnome-desktop-3.so.17 #4 0x7fa9951a9221 in e_icon_factory_create_thumbnail () at /usr/lib/evolution/libevolution-util.so.0 #5 0x7fa995138c96 in () at /usr/lib/evolution/libevolution-util.so.0 #6 0x7fa997ebcdd8 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0x7fa997ebd1c8 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x7fa997ebd4c2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x7fa998457b15 in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #10 0x56489140cee4 in main (argc=, argv=) at ./src/shell/main.c:676 ___ 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] Upcoming evolution-data-server API changes (libical-glib + more)
On Fri, 2019-04-12 at 08:47 +0200, Milan Crha via evolution-hackers wrote: > this is kind of heads-up e-mail about upcoming API changes in > evolution-data-server. Hi, just a notice that the changes landed for the 3.33.2 development version. Some more info and history can be found in this [1] thread, which split to May [2]. Bye, Milan [1] https://mail.gnome.org/archives/desktop-devel-list/2019-April/msg00016.html [2] https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00085.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] evolution failing on TLSv1.3 after gnutls upgrade
On Wed, 2019-05-15 at 15:49 -0700, James Bottomley wrote: > gnutls Add support for timeouts on GnuTLS pulls > > So if you apply that on top of 2.54.1, the test programme works > again. Hi, do you see from the server logs whether the patched code tried TLS v1.3, and then v1.2? I'm only wondering. After re-reading the previous messages in this thread, you found that the development version 2.55.2 works fine. As it's a development version, the (usual) distributions may pick the stable version, 2.56.0 or later. Or they can find which patch fixed it between 2.55.1 and 2.55.2 and backport only that one (you referenced that change above). Thinking of it, maybe it's a nonsense to ask them about the TLS version downgrade on the fly. My "suggestion" would be over-complicated. In any case, thank you for your time and help on this. 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] evolution failing on TLSv1.3 after gnutls upgrade
On Mon, 2019-05-13 at 07:59 -0700, James Bottomley wrote: > As for how to apply the fix (assuming we can find it), this is a hard > one. Clearly the bug was always present, but the conditions that > trip it remained untested until people started turning on TLSv1.3. > I think the best way forward is to open bugs with the distros and see > what they want to do: Either find and fix the bug or update to 2.55.2. Hi, I see. That would work until a new version of the TLS is released and implemented and advertised by the servers with clients which probably know about it (due to new enough gnutls being installed, right?), but its usage in glib-networking failing for whatever reason. > Just to clarify, the server isn't requiring a particular version, > it's offering a set of options and we're choosing TLSv1.3 which we > then can't negotiate successfully, so the bug is client side but > triggered both by the client going to a gnutls (or probably openssl > but I can't test that) version that makes 1.3 possible and the server > offering it as an option. Oh, you are right, I'm sorry for misinterpreting it. Maybe the glib-networking can be changed to try a lower version(s) (when allowed to), when the best it thinks it can use fails with this error (meaning if the server advertises TLS versions 1.2 and 1.3, the client can try with 1.3 and if it fails, then retry with 1.2). I'd expect such naive "solution" would work on the gnutls level transparently though. I do not know gnutls, nor glib-networking, thus this is really just a very naive idea. Consider filling a bug against glib-networking [1] and ask them whether they can do anything about it. You've a clear view what is going on in the background, thus you'd be able to explain the problem to them. Feel free to use the test program to your liking. By the way, the openssl implementation for glib-networking is very new, released as part of the 2.60.0, on March 11 [2]. Bye, Milan [1] https://gitlab.gnome.org/GNOME/glib-networking/issues/new [2] https://gitlab.gnome.org/GNOME/glib-networking/blob/2.60.0/NEWS#L1 ___ 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] evolution failing on TLSv1.3 after gnutls upgrade
On Sun, 2019-05-12 at 11:04 -0700, James Bottomley via evolution- hackers wrote: > On Fri, 2019-05-10 at 23:23 +0200, Sasa Ostrouska via evolution- > hackers > wrote: > > Hi all, and thanks Milan for the program. I also run an old version > > of evolution 3.20.x and I get the following: Hi, the more important is glib/glib-networking/gnutls version, than evolution(-data-server) version. Sometimes also the system crypto policy setting (/etc/crypto-policies/config on Fedora), though it works the other way, it disables the old algorithms and "forces" use of the newer, which can break connection against legacy servers. > > rc@rc-laptop:~/Downloads$ gcc `pkg-config --cflags --libs glib-2.0 > > gio-2.0` imap-conn.c -g -O0 -o imap-conn && ./imap-conn > > imap.googlemail.com 993 > > Connected to imap.googlemail.com:993 > > Failed to read data from the server: Error reading data from TLS > > socket: The specified session has been invalidated for some reason. The error is returned from gio/glib-networking and I agree it's not obvious what it is about. Maybe it means that the current code doesn't have new-enough implementation of the TLS. It looks like that, at least. > > I neded to #include on my slackware linux. > > Me too, but it was a trivial update. Hrm, weird, it might be probably due to that strlen() usage. No idea what pulled it in here, that it didn't claim any issue on my side. I'm sorry about that. > I think the solution is to simply bar glib-networking below 2.55.2 > from using gnutls VERS-TLS1.3 which looks like it can be done > reasonably well in g_tls_connection_gnutls_init_priorities() There are some issues with it: a) the function is a private function, I didn't find it in any of the header files under /usr/include/; b) it's a very specific function, there's a branch to support also openssl in glib-networking, where this would do nothing; c) getting such change into an old evolution-data-server or glib-networking might be tricky, especially with Long Term Support distributions; d) as Sasa showed (if I understand it correctly), limiting TLS version may lead to rejected connections on otherwise working system (it's when the server increases TLS version requirement, but the "proposed change" would limit what can be used). That said, when the server requires recent TLS version, the users need to update their system to also support such TLS version. It makes sense (once one knows where the problem is, which I wasn't sure at all at the beginning). Thank you James for all the testing and finding that out. It's good to know that glib has it fixed already. 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] evolution failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-09 at 11:03 -0700, James Bottomley wrote:
> I can certainly test things out.
Hi,
that's great, thanks.
> To be honest, I've had problems with TLSv1.3 every time it's been
> negotiated, so disabling it is a reasonable thing to do.
I see. If you are still willing to help, then it'll be appreciated.
> I suppose there's no gntuls-cli equivalent for glib-networking? That
> would be the best way to test it.
I agree, but I'm not aware of anything like that (which doesn't mean it
doesn't exist). I made a little test program as promised, see the
attachment. The first line contains a comment with a command to compile
and run it (against Google's IMAP server). It's only a test program,
mimic-ing what Evolution (or better Camel library from evolution-data-
server) does. You may have installed development packages for glib and,
if split, also for glib's gio, to be able to compile it.
Bye,
Milan
P.S.: The result of the run as is in the file itself is below:
$ ./imap-conn imap.googlemail.com 993
Connected to imap.googlemail.com:993
Response: * OK Gimap ready for requests from {IPADDRESS} {SOMETOKEN}
Request: A01 CAPABILITY
Response: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST
CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN
AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH
A01 OK Thats all she wrote! {SOMETOKEN}
Request: A02 LOGOUT
Response: * BYE Logout Requested {SOMETOKEN}
A02 OK Quoth the raven, nevermore... {SOMETOKEN}
/* gcc `pkg-config --cflags --libs glib-2.0 gio-2.0` imap-conn.c -g -O0 -o imap-conn && ./imap-conn imap.googlemail.com 993 */
#include
#include
static gboolean
read_stream_data (GIOStream *stream)
{
GInputStream *input;
gchar buffer[2048 + 1];
gsize count;
GError *error = NULL;
input = g_io_stream_get_input_stream (stream);
count = g_input_stream_read (input, buffer, G_N_ELEMENTS (buffer) - 1, NULL, );
if (count == -1) {
if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_TIMED_OUT)) {
g_clear_error ();
} else {
g_printerr ("Failed to read data from the server: %s\n", error ? error->message : "Unknown error");
g_clear_error ();
return FALSE;
}
} else {
buffer[count] = 0;
g_print ("Response: %s\n", buffer);
}
return TRUE;
}
static gboolean
issue_command (GIOStream *stream,
const gchar *command)
{
GOutputStream *output;
gsize count, written = 0;
GError *error = NULL;
output = g_io_stream_get_output_stream (stream);
count = strlen (command);
if (!g_output_stream_write_all (output, command, count, , NULL, )) {
g_printerr ("Failed to write command to the output stream: %s\n", error ? error->message : "Unknown error");
g_clear_error ();
return FALSE;
}
if (written != count) {
g_printerr ("Wrote only %d bytes, instead of %d\n", written, count);
return FALSE;
}
if (!g_output_stream_write_all (output, "\r\n", 2, , NULL, )) {
g_printerr ("Failed to write command end to the output stream: %s\n", error ? error->message : "Unknown error");
g_clear_error ();
return FALSE;
}
if (written != 2) {
g_printerr ("Wrote only %d bytes, instead of %d\n", written, 2);
return FALSE;
}
if (!g_output_stream_flush (output, NULL, )) {
g_printerr ("Failed to flush output stream\n", error ? error->message : "Unknown error");
g_clear_error ();
return FALSE;
}
g_print ("Request: %s\n", command);
return read_stream_data (stream);
}
static gint
run_connection (const gchar *host,
gushort port)
{
GSocketConnectable *connectable;
GSocketConnection *connection;
GSocketClient *client;
gint ret = 0;
GError *error = NULL;
connectable = g_object_new (G_TYPE_NETWORK_ADDRESS,
"scheme", "imap",
"hostname", host,
"port", port,
NULL);
client = g_socket_client_new ();
g_socket_client_set_timeout (client, 10);
g_socket_client_set_tls (client, TRUE);
connection = g_socket_client_connect (client, connectable, NULL, );
if (connection) {
GSocket *socket;
GIOStream *stream;
g_print ("Connected to %s:%d\n", host, port);
socket = g_socket_connection_get_socket (connection);
if (socket) {
g_socket_set_timeout (socket, 10);
g_socket_set_keepalive (socket, TRUE);
}
stream = G_IO_STREAM (connection);
if (!read_stream_data (stream))
ret = 3;
else if (!issue_command (stream, "A01 CAPABILITY"))
ret = 4;
else if (!issue_command (stream, "A02 LOGOUT"))
ret = 5;
if (!g_io_stream_close (stream, NULL, )) {
if (!ret)
ret = 6;
g_printerr ("Failed to close connection: %s\n", error ? error->message : "Unknown error");
g_clear_error ();
}
g_object_unref (connection);
} else {
g_printerr ("Failed to connect to %s:%d: %s\n", host, port, error ? error->message : "Unknown error");
g_clear_error ();
ret = 2;
}
g_object_unref (connectable);
g_object_unref (client);
}
gint
main (gint argc,
gchar *argv[])
{
const gchar *host;
gushort port;
if (argc != 3) {
g_printerr ("Requires two
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-09 at 08:37 -0700, James Bottomley via evolution- hackers wrote: > On OpenSUSE running evolution-3.26.6-lp150.2.6.x86_64, installing > > gnutls-3.6.7-lp150.9.1.x86_64 > > Lead to evolution failing on my dovecot imap server with > > Error reading data from TLS socket: The specified session has been > invalidated for some reason Hi, dealing with such requests is better either through the user list (evolution-list), or through bugzilla - see the "bugs" section of: https://wiki.gnome.org/Apps/Evolution/#Online_Support not talking that your Evolution it rather old, the current stable version is 3.32.2. Nonetheless, I do not expect that Evolution update would help, because Evolution doesn't use gnutls. It doesn't use it directly. Evolution relies on glib-networking and on whatever it uses, which is gnutls in this case. I guess those developers would appreciate any help, especially if the code is broken for them. If you wish, I can try to create some simple test program (a .c file), which would open a stream towards specified server and ask for capabilities or something, which can be done in an unauthenticated state, on which you can verify: a) it's really in glib-networking, b) whether more recent version of it will help. 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] Upcoming evolution-data-server API changes (libical-glib + more)
Hello, this is kind of heads-up e-mail about upcoming API changes in evolution-data-server. I also do not like them, but they are sometimes necessary. The first part is about porting the calendar to use libical-glib [1], instead of libical, in order to finally provide introspection for it. The change was so huge that it deserved an API bump from 1.2 to 2.0 (libecal-1.2 and libedata-cal-1.2 will become libecal-2.0 and libedata-cal-2.0). The API around ECalComponent and its structures had been made introspection friendly too. I took the opportunity and removed all the deprecated and obsolete stuff from libecal and libedata-cal. This work depends on the unreleased libical git master, but there's planned a 3.0.5 release of it with the necessary changes. The second part was about preparation for passing flags from the client towards the backend to influence behavior. It was initially meant for this issue [2], but I extended it to pass also information about conflict resolution for write operations. This change touched all the APIs - the client side API, the server side API and the D-Bus API. The last is probably the most disturbing, at least in case of the Flatpak applications, which build against some version of the evolution-data- server, but rely on the host system evolution-data-server (it's possibly broken on both sides, aka building with new eds, but run with old, or build with old eds, but run with new). I'd say the best option for such applications is to run the eds services inside the Flatpak sandbox, which has the advantage that also the server side fixes are included in the application, not only the client side fixes. It has a downside, the downloaded data and configurations are not shared with the system. I guess it's a downside of Flatpak in general, but that's only my opinion. I made the same changes (for the [2]) for libebook, libebook-contacts and libedata-book, where I also changed some defines (added E_ prefix) and dropped EDataBookStatus error enum, which had not been really needed (similarly as I dropped EDataCalCallStatus). It could be replaced with EClientError and EBookClientError. As with the calendar, this touched the D-Bus API too. These book changes are quite straightforward. All the changes are prepared in this side branch: https://gitlab.gnome.org/GNOME/evolution-data-server/tree/wip/mcrha/libical-glib The 'make check' passes without errors. I already have prepared evolution, evolution-ews and evolution-mapi, though only as a buildable. The testing is to-be -done, I only didn't want to block this due to these three projects. Looking into the other API users, I found these hosted on GNOME: almanah bijiben california ekiga evolution-activesync folks glabels gnome-calendar gnome-contacts gnome-phone-manager gnome-shell gnome-todo I plan to create 'wip/mcrha/eds-libical-glib' branches in each and help with porting as much as I can. The idea is that the maintainers will just merge the branch changes and it'll be all (from the coding point of view). I know the branch name is inaccurate for the book changes, but I decided to keep all these things in one branch for simplicity. I believe it's better to break the API in a single release, instead of doing that within multiple releases. It will make it easier for the maintainers of the applications - the porting effort will be done only once, not multiple times. I have in my list these additional projects (to be verified whether any changes are needed there and help with them if yes): elementary-calendar ffgtk libopensync-plugin-evolution2 libreoffice pidgin-chime sflphone syncevolution wingpanel-indicator-datetime If you know more, then feel free to let me know. I'll be happy to help with the porting. With respect of timing, my plan was to have the things prepared for 3.35.1, I expected that the changes will take longer, but it went quite smoothly (well, actual testing will take some more time). I definitely want to wait for an official release of libical 3.0.5 with the necessary changes in its libical-glib part. Then we can decide, depending in what state respective projects will be. Maybe it'll be possible for 3.33.2 or shortly after it. I definitely do not want to push this close to the end of the development phase, I'd rather do this in the beginning of it, thus any third-party projects have enough time for porting. That's another reason why I chose 3.35.1 initially. I know this change will break some GNOME infrastructure, like the GNOME Continuous effort, thus it's understandable to have the critical projects prepared/ported first and commit the things (almost) at the same time. This would need some coordination, which is another reason for this e-mail. I do not foresee any additional API changes currently, definitely not on the D-Bus side, thus once this is done, the API should stay stable for the next several years, I believe. Of course, everything depends
Re: [Evolution-hackers] single-key keyboard shortcuts
On Tue, 2019-04-09 at 09:13 -0600, Zan Lynx wrote: > This insistence on stupid "Control-]" instead of "n" was one major > reason. Hi, plain ']' and '[' work too here. Not talking about "magic spacebar" feature [1]. Just that you know. Bye, Milan [1] https://help.gnome.org/users/evolution/stable/mail-reading-keyboard-shortcuts.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] single-key keyboard shortcuts
On Tue, 2019-04-09 at 16:15 +0200, Lukas Pirl wrote: > I tried ``.config/evolution/accels`` which works in principle but > introduces the usability flaw that the actions are also triggered > in input fields Hi, what is the evolution version you use, please? Do you have exact steps, please? I'm pretty sure the search entry is covered by the below functions. At least the latest 3.32.1 (released only yesterday) should be fine, I think. > Can we prevent single-key shortcuts to be triggered in input fields > generally? There's a code which does that, but, well, it's buggy "a bit". > Or can we write a plugin which catches single-key shortcuts > and triggers therein configured actions? If so, how would such a > plugin look like code-wise? Are there similar plugins to get > inspiration from? No idea how such plugin would look like, neither I'm aware of any existing plugin of this kind (to add shortcuts). The usual way is to edit the accels file, as you did. There's an example module here: https://wiki.gnome.org/Apps/Evolution/Extensions#Example_Module with which you can start, if you want to, but I'm afraid I cannot help you with the accelerators. An EShellWindow has e_shell_window_get_need_input(), similarly EWebView has e_web_view_get_need_input(), which is used to not trigger any action when the widgets need the input. 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] Icons
On Mon, 2019-02-11 at 09:08 +0100, Mads Rosendahl via evolution-hackers wrote: > Is there some kind of guide for the toolbar icon lookup? Hi, icons provided by Evolution itself should be available always, all the other are following naming as used by the default Adwaita theme. Many names are referenced for example from here (note the stock icons are deprecated, I use this reference only because there are also provided corresponding icon names for those deprecated): https://developer.gnome.org/gtk3/stable/gtk3-Stock-Items.html#GTK-STOCK-ABOUT:CAPS Where Adwaita/gtk+ took those names I do not know, I'm sorry. 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] empty folders being created in Evolution
On Tue, 2019-01-29 at 16:03 -0500, James R. Overstreet via evolution- hackers wrote: > Why are blank / empty folders being created > in Evolution file structure at: > > ./local/share/evolution/mail/alphanumeric-folder/cache > > I think these folders used to be used to store > old emails that were emptied from trash but looks like > they are no longer being used for that purpose. Hi, could you be a bit more specific, please? Stating what Evolution version this is about and what account type this is about will help. Knowing what empty folders you do not like would help as well. Apart of that, why are empty folders of an internal directory structure of some software a problem for you, please? 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] Building the Latest Source of Evolution
On Tue, 2019-01-22 at 10:09 +0100, Andre Klapper wrote: > https://packages.ubuntu.com/ allows searching for package names that > the "Ubuntu" distribution uses. I entered "libecal" on that website > and it listed "libecal1.2-dev" for development. Is that package > installed? Hi, building evolution-data-server and evolution from sources means using those built versions, not the system versions, especially when the system version is not the same as the one being built. Better to not install development packages for the system packages you are building, to avoid confusion in the build time (and eventually in the runtime, but that's harder and doesn't depend on the development packages, but runtime packages). 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] Building the Latest Source of Evolution
On Mon, 2019-01-21 at 22:32 -0500, Dr. Jason Amerson wrote: > I am trying to build Evolution Data Server and Evolution using the method > outlined in the Wiki. Hi, I suppose you mean: https://wiki.gnome.org/Apps/Evolution/Building > I was able to successfully get through the > instructions for Evolution Data Server. I have stalled on the part to > configure the build before make && make install. I am being told that the > packages libebook-1.2 and libecal-1.2 are not found. Those are provided by evolution-data-server and installed (as part of `make install`) to the prefix you specified. Using the steps as they are written on the Wiki (see above) makes it bullet proof, thus I guess you made your own modifications, which diverged from the steps. As the first try, I'd make sure you run `source $HOME/sources/build`, aka you've properly setup the environment, as outlined here: https://wiki.gnome.org/Apps/Evolution/Building#Set_up_environment Maybe consider the flatpak build, which is simpler to run: https://wiki.gnome.org/Apps/Evolution/Flatpak or even better install the flatpak Evolution from flathub.org, which saves you time, because you get working copy without a need to compile anything. 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] Problems with calendar notification under unity (eds >= 3.30)
On Fri, 2019-01-04 at 14:07 +0500, Khurshid Alam wrote: > We can always query org.freedesktop.Notifications for that. Here is > basic patch that is working. Hi, it can be done, but it also means some kind of expectation in the code. What if the system the glib is running on uses different method for its GNotification-s? That's why it's more correct to (add and) use glib API. Imagine the same on MacOS or Windows, I doubt Windows implementation uses org.freedesktop.Notifications (if GNotification works there at all, because the developer documentation gives no guarantees). I'm not against the change, it can be added at least temporarily, until glib adds the needed API. > https://paste.ubuntu.com/p/Td4nGvWq2v/ Could you open a bug report against eds and add the patch there, please? I briefly read it, I didn't compile it, and it has some issues: a) an error message says "system bus", but you open session bus b) "to look up" in the error message sounds weird, neither I'm sure why you add g_get_user_name() into that error message. c) I'd prefer to use g_strcmp0() and g_clear_error() with changed 'error->message' to 'error ? error->message : "Unknown error"', just in case d) the code introduces a compiler warning (variables defined in the middle of the code block) e) the 'str' can leak f) the 'bus' can leak g) ideally call this only once and remember the result; it's highly unlikely that the notification server will change its capabilities in runtime, at least from my point of view, and D-Bus calls can cause delays. Having opened a related glib bug is also required, thus they can be linked together. Well, liked in a sense of gitlab, not the real linking with all the notifications and such as bugzilla used to do. > By default it doesn't add action if server doesn't support it, but it > can be made to do it. The default is fine. > This probably can't go in upstream since indicator-messages is not in > debian, but ayatana-indicator-messages is. Right, I'd like to avoid desktop environment specific code as much as possible. Also because that can require desktop specific libraries, which can limit the places where the code can be developed (as you enabled the MM in the DISTCONFIGURE parameters). Not talking that such code makes it harder to test properly (more code paths to verify by the testers and/or builtin tests). I'm thinking whether it would be helpful to make EAlarmNotify an extensible. In that case you could write an extension for it (instead of patching upstream code), that could live in your repositories. I'm not sure whether it might make things easier or worse for you, though. 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] Problems with calendar notification under unity (eds >= 3.30)
On Wed, 2018-12-19 at 13:21 +0500, Khurshid Alam wrote: > Hi Milan, Hi, I hope you know you address a mailing list with many subscribed users. It's fine by me (better than private email), but not everyone here is named 'Milan'. :) > In unity we also set notify-with-tray to false, so both dialog is > appearing at the same time. For the time being I set notify-with-tray > to true. Once GNOME Shell's #155 is closed/fixed, you won't use that. It had been expected (by me) to be in 3.30, but it didn't happen. > Will it be possible to check notification server capabilities before > adding an action ? There's used GNotification and after a brief look I do not see any glib API which would allow to verify whether the notifications can have actions or not. That might be a call to them, to add such API, then evolution-data-server (eds) can use it. The eds doesn't use libnotify directly intentionally (it has less dependencies, especially when the same/similar API is provided by glib). > But now since it is in eds I think it's better that we drop > notification related code fr om indicator-datettime. There is no > point replicating entire EReminderWatcher code into into it. I'm afraid it's not a question for me. You can disable evolution-alarm- notify autostart in its .desktop file for Unity and have things working as before, regardless whether users have installed also Evolution or not. At least for the time being, until that GNOME Shell's #155 is done. > For 2) I have a prototype code, it can be patched in eds or we can do > it from indicator-datetime or patch downstream. What would you exactly change on the eds side? > 3) Is there bus signal we can watch when a notification-tray appears > ? I am watching "notify" signal from ca.desrt.dconf.Writer and > checking 'reminder-past' in 'org.gnome.evolution-data- > server.calendar', but that's not very productive. I think the GNotification works on D-Bus, thus look there. Whether you'd be able to distinguish between notifications sent by evolution- alarm-notify and other notifications I do not know. Alarm notify itself doesn't send any special D-Bus signals. Again, all your work and time spent on this is only due to GNOME Shell's #155 not being fixed yet (well, as long as Unity derives from GNOME Shell). I think, if you've everything already implemented in Unity, then the easiest would be to just disable evolution-alarm-notify in Unity and avoid all the trouble pretty easily. Hope it helps. 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] Automatically start services from install path
On Thu, 2018-12-13 at 02:47 +0100, Marek Howard via evolution-hackers wrote: > Is there any way to build evolution to make it automatically start > the required services from correct installed path on startup, just like the > system installed Evolution does? Hi, it's not about Evolution build, it's about setting D-Bus to search for the built services, not for system services. The text in the referenced wiki page didn't want to come into too much detail in this regard, there are better articles how to setup D-Bus with it. The .service files are installed into $PREFIX/share/dbus-1/services/, which is the path you want to tell D-Bus to look for the services first. That D-Bus doesn't know about these .service files is the reason why it starts system-installed services when you run built Evolution. There can be some differences when also systemd files are involved, but I'm not sure what to do with it off head, I'd search the same as you might search the web, if you (or the system-installed evolution-data-server) use systemd. 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] Latest Evolution version on Windows 10
On Mon, 2018-11-12 at 12:55 +, Leonardo Costa Fiorini via evolution-hackers wrote: > But I use Windows 10 in a corporate environment and > therefore this is not possible, unless somebody here knows something > about any recent packages designed to work on Windows 10. Hi, if there is anything precompiled for Windows out there I do not know, I'm sorry. Evolution itself cannot be compiled for Windows at the moment, because it depends on WebKitGTK+ and its usage of WebKit2, which does not compile on Windows right now [1]. Having it done the rest will "just work". That is, either you install some sort of Linux emulator to get to the latest version of Evolution [2][3], or you would use a virtual machine with installed Linux and eventually also precompiled Evolution. Bye, Milan [1] https://bugs.webkit.org/show_bug.cgi?id=137488 [2] https://wiki.gnome.org/Apps/Evolution/Building [3] https://wiki.gnome.org/Apps/Evolution/Flatpak ___ 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] Request for help on hacking evolution composer
On Sun, 2018-10-21 at 20:44 -0400, John Wiseman wrote: > I am running Evolution 2.32 on RHel 6.9 so this is a bit older > version. Hi, it's not "a bit older" version, it's an ancient version. The current stable version series is 3.30.x. In your version, if I'm not mistaken, the code you are looking for is in gtkhtml3, not in evolution itself. The code moved to evolution when it had been ported to WebKitGTK+ years later. 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] Markdown support in evolution's message composer
Hi, On Tue, 2018-08-14 at 17:21 +0200, Thomas Flori via evolution-hackers wrote: > I presume that every developer knows the markdown syntax I'm afraid I'm the one whom doesn't, thus not every, really. Furthermore, Evolution as such targets wider audience than only developers, somehow. > It does not compete with the client design This is questionable, isn't it? First of all, which client do you mean? That which composes the message, or that which receives the message? That which composes needs additional functions, if it is supposed to convert the markdown into HTML, as you suggested below. That means you do touch the client design. Without conversion it's different, it can be just a Plain Text document and the understanding of the markdown might be moved to the receiving side, which also means to add some design changes on that side. > It can be viewed as text without being unreadable Right, so it suggests you do not want to use HTML, but you want Evolution to convert it into HTML, as written below. This it might be still HTML at the end, hence this markdown advantage is void here. > It can be written faster and without using the mouse I can write HTML code without mouse too, I do not remember when I used mouse to write HTML code in a notepad the last time, the most when selecting some portion of the text, which doesn't have anything to do with the HTML code as such. Regarding the Evolution composer itself (where one doesn't write direct HTML code), you are right that some functions are easier accessible with the mouse, but most of them have short-cuts and/or are accessible through menu, thus also without a need of the mouse. You might also compare the same set of functions/formats, when comparing the two methods (like when switching for example bold, then you simply press Ctrl+B in Evolution and that all). > The idea is to write in markdown. In the message compose options you > choose "WYSIWYG" or "MarkDown" and when you write a message you just > get a text box (above the quoted emails). When you send the message > the message gets converted to html before it gets send. > ... > I would really prefer to write my emails with markdown in evolution. You can always write an enhancement request for Evolution at its issue tracker: https://gitlab.gnome.org/GNOME/evolution/issues/new I didn't find anything for "markdown" in the old https://bugzilla.gnome.org for the evolution product. 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] Fetching S/MIME Certificates from LDAP
On Wed, 2018-06-20 at 11:35 -0400, Vincent Lucarelli via evolution- hackers wrote: > Trying to figure out if it should work and I have something wrong, or > if support for this feature never made it into the stable release. Hi, unfortunately, it's still not in the sources. Watch this bug [1] for any further progress (maybe it'll be included in 3.30.x, but no promises). Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=704246 It also blocks a bug which specifically talks about certificates in LDAP address books. ___ 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] Why X-Mailer instead of User-Agent?
On Tue, 2018-05-29 at 10:10 +0200, Milan Crha wrote: > ... thus it's probably because nobody noticed. Hi, just a note, Evolution 3.30.0+ will use User-Agent instead of X-Mailer header when sending messages: https://gitlab.gnome.org/GNOME/evolution/commit/dd8c825956 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] Nor “Answer to list”, nor “answer to all” make use of “Cc” …add “wide answer”?
On Wed, 2018-05-30 at 12:04 +0200, Garreau, Alexandre wrote: > > Right, it's part of the development version. To be released in > > 3.30.0+. > > Oh ok, I’m still under Debian stable so I probably don’t have access > to it… Hi, the 3.30.0 stable version of evolution is to-be-released later this year. > What does it do? It lets you reply with a different style than you use otherwise, aka you can override global/account settings for reply function with it. https://bugzilla.gnome.org/show_bug.cgi?id=602612 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] Thread Stealing (Was: Re: Nor “Answer to list”, nor “answer to all” make use of “Cc” …add “wide answer”?)
On Wed, 2018-05-30 at 01:43 +0200, Garreau, Alexandre wrote: > If you inspect the In-Reply-To headers you’ll see none of these is > marked as an answer to another, yet References mark them because some > of them do reference the other ones. Hi, I highly doubt any regular user even knows anything about the internals. They care of the result. And what you did has the result as shown in the attachment. That's a very good habit to discuss one issue in one thread (or even bug report), though I agree it's not always possible. While you think the things are related, then the X-Mailer has nothing to do with Reply- to-List (it just happened that you wrote both messages), still if I'm not interested in the X-Mailer thread then when I collapse it (or mark it to be ignored) I lost track of the other threads. I also expect that you did put some effort to have the References header filled in the other messages, which just shows that even you can do that manually, regular users will not do it, unless they have tools for it. Anyway, we diverged from the subject from my point of view, we just discuss our habits and preferences, which obviously differ. Each has its pros and cons, I'm not questioning that. My personal past experience is that changing someone habits is pretty hard (near to impossible), no matter what any document can suggest as the best practice. Again, consider regular users, corporate environments (top posting), incorrect quoting, when people cannot distinguish between instant messaging and e-mail (they try to use instant messaging habits in e-mails, huh) and so on. 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] Nor “Answer to list”, nor “answer to all” make use of “Cc” …add “wide answer”?
Hi, On Wed, 2018-05-30 at 03:04 +0200, Garreau, Alexandre wrote: > Should we cross-post to evolution-list Cross-posting is considered bad too. You can just start new conversation there. > ...to that private mailing list from the outside, ... Right, private and public mailing lists can have different rules. > I didn’t understand… you receive the message then, right? Yes, but not from the list. > Though contrarily to Evolution, the later > differentiate between “To:” and “Cc:” header (Evolution puts > everything in “To:” Hmm, as far as I can tell, Evolution preserves the CC header content. > and all the rest (that were in the “To:”, “Cc:” and “Bcc:”) in the > “Cc:”. I do not agree, there is a reason why there are people in Bcc. They should not be exposed in To or CC. > What’s the difference between Group Reply, Reply to all and Reply to > list then? You can configure what Group Reply does, according to your preferences/habits. > Alternative Reply? Right, it's part of the development version. To be released in 3.30.0+. > “Complicated” doesn’t mean complete, complex or big, and “Evolution” > may metonymically refers to its UI as well. There had been a criticism that the menus are too long already. I refer just to that. 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] Nor “Answer to list”, nor “answer to all” make use of “Cc” …add “wide answer”?
On Tue, 2018-05-29 at 02:48 +0200, Garreau, Alexandre wrote: > (not the same thing as a thread may change > topic by having one of its participant changing its subject line) Hi off topic: a) I'm replying intentionally to the list b) I'm talking to you, the person written at the very first line of this mail, because "Garreau, Alexandre wrote:" c) I do not know how much intentionally you did it, but you wrote three different topics here, in a way that there is one thread which covers all three topics in a very sad way. They use to call it "thread stealing". Yours "writing privately to the list" is a nonsense (I'm sorry, I'd use a softer term if I knew such), the mailing list is a public place, not private. I do not know what your use case or work flow is that you notice messages where you are in To/Cc better than messages directed only to the list where you are subscribed (I'd guess as long as they are directed to the list too they end at the same folder), but okay. That only proves that different people have different habits and use cases. To be honest, I hate when people reply to all in the lists. It breaks reply to the list, because I receive messages directed only to the list (when I'm not in To/CC, there's a setting in mailman for it, which avoids duplicate mails), that means that reply to all makes things worse for someone. It makes sense to reply to the list, it's the place where the thread begun, thus it should stay there, in the public. As Ángel said, if you are not subscribed, then you can say so and people will keep you in the loop. Doing it "only because you can" (like by adding such notice into your signature regardless of actual state) might not be ideal. Again, different people, different habits, different preferences. People using reply-to-all, because either they do not know reply-to-list or their mail client doesn't offer it to them is no argument to keep using reply-to-all, just the opposite. Back to the matter, Edit->Preferences->Composer Preferences->General tab->[x] Group Reply goes only to mailing list, if possible. That's probably the option you are looking for. With that off the Ctrl+L still goes to the list only, but the Group Reply goes to all. For me, there's Reply to Sender, Reply to All, Reply to List, Group Reply and now also Alternative Reply. Adding another reply kind, maybe with a short cut, especially in a world where there's a tendency to make things simpler, rather than more complicated (there are complaints that Evolution it already too complicated, you repeated that several times too), could not add to the thing. I also do not understand how you'd recognize when to use reply-to-all instead of reply-to-list-and- From. There can be people in the To/CC whom are not subscribed to the list, thus you'd just remove them from the loop, which is wrong (I know, you wanted to reply to the list and the To addresses, but that's not correct, because the To can be the mailing list and all the other people in the loop could be in CC, while you are replying to the person in the From header). By the way, this particular question belongs to evolution-list, rather than to evolution-hackers. The later is for coders, while you are discussing user functions. Not a big deal, just saying. 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] Why X-Mailer instead of User-Agent?
On Mon, 2018-05-28 at 19:45 +0200, Garreau, Alexandre wrote: > In both occurence I noted the usage of, non-standard as far as I > understood, “X-Mailer” header rather than the, standard as far as I > understood, “User-Agent” one [1]. Hi, as your link says, it's non-standard but standardized header for this information. > Why so? Is there a reason, or did just this stayed this way since > 2009? Yes, I believe it's it, it just stayed such and either nobody noticed or nobody had time to change it or anything like that. I didn't find a bug report for it, thus it's probably because nobody noticed. 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] MH backend for storing mail
On Mon, 2018-05-28 at 20:24 +0200, Garreau, Alexandre wrote: > I’d like to know where did you find a good enough specification of > “exmh .folder” format (except evidently exmh’s source code itself) Hi, I'm afraid it's a question for original authors of the code, whom do not work on the project anymore. How much the binary format is usable between different projects is another good question. 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] Preformat by default
On Sat, 2018-04-07 at 23:03 +0200, Marek Howard wrote: > I'd like to change Evolution composer in plain text to use Preformat > block format by default. Below you can see what I did but the default > block format is still set to Normal/Paragraph in new messages. Hi, it's because you changed the variables, but not the HTML structure, which these variables modify. You can verify what the message structure is when you press Ctrl+Shift+I when the composer body is focused, which will open a WebKit inspector (you might have org.gnome.evolution.shell webkit-developer-mode set to true). I recall something about an issue with cursor positioning around HTML tags, thus even if the structure will be fine, the cursor can be slightly off the proper place. In any case, I'd try to call the method of the EContentEditor, which in this case is not to do this: >- ACTION (STYLE_NORMAL), "current-value", >+ ACTION (STYLE_PRE), "current-value", but do rather this: e_content_editor_set_block_format (cnt_editor, E_CONTENT_EDITOR_BLOCK_FORMAT_PRE); > I'm not that used to mailing list etiquette. Is the way I attached > the patch proper? I think it depends on the community. While some communities prefer patches inline, it's not the case of this mailing list (you know, you didn't attach it by any means). But as long as you do not want to upstream the change it doesn't matter. By the way, you would be able to do this as a module, without touching evolution code at all. You can use the example module as a starter: https://wiki.gnome.org/Apps/Evolution/Extensions#Example_Module only its MMsgComposerExtension, and change the code to your liking, would be the end of the m_msg_composer_extension_constructed() function, definitely after the call to parent's constructed() method. The advantage is that you won't touch evolution code, thus you'd be able to use stock evolution, only rebuild your module from time to time (supposing you have write access to the module directory). 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] lookup S/Mime encryption certificates over LDAP
On Mon, 2018-02-12 at 09:28 +0100, Horst Weber wrote: > Is there a plan for fixing this issue? Hi, you are right, neither the current stable 3.26 nor your ancient 3.18.5 support that, but the bug exists for it. The older one: https://bugzilla.gnome.org/show_bug.cgi?id=203251 is specific for LDAP, but I expect it to be fixed with a newer: https://bugzilla.gnome.org/show_bug.cgi?id=704246 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] Support alternative concepts to organise mail communication?
On Fri, 2018-01-19 at 08:12 -0500, Adam Tauno Williams wrote: > > - Send later > > Send @ [time] would be somewhat useful. Sounds complicate to > implement though. Hi, there is something in-between. In Edit->Preferences->Composer Preferences one can set Evolution to send messages through Outbox (the only one related is On This Computer/Outbox). A suboption contains Immediately, Keep in Outbox and Send after 5 minutes. It's not the same as "@ [time]", I know, but it's close to it. Anna, I think you would get more opinion on the subject when sending to evolution-list, which is the list for the users, thus you can get more information from people whom use and care of Evolution (I do not mean hackers do not care of Evolution, errr, I hope you know what I mean). :) 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] Support for Autocrypt?
On Mon, 2017-12-18 at 21:25 +0100, Anna Marei wrote: > What about Evoulution? Hi, just for the record, there's filled: https://bugzilla.gnome.org/show_bug.cgi?id=792045 for it. 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] Support for Autocrypt?
On Tue, 2018-01-02 at 16:32 +0100, Tobias Mueller wrote: > How feasible is it, though, to implement this as a plugin to > Evolution? > AFAIU it would need to be able to get the context in terms of what > headers the currently replied-to email has. Hi, I read the project page only briefly, and one thing there was that the client stores the GPG keys somewhere once they are received and any further communication is done encrypted (it implies to me that really any further communication, not only that single thread, but I can be wrong). Adding the header to to-be-send message is particularly easy, the composer has a signal emitted before sending. Checking which message had been replied to is tricky, that may eventually require some changes. Passing custom keys into GPG through CamelGpgContext is not doable at the moment, neither extracting the key from the key ID (there is saved only the key ID in the account preferences). The context relies on keys stored within gpg itself. Thus, rather than a plugin, it might be done directly in evolution(- data-server). 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] Support for Autocrypt?
On Tue, 2018-01-02 at 10:12 -0500, Martin Owens wrote: > On Tue, 2018-01-02 at 13:45 +0100, Milan Crha wrote: > > thus there's a problem with interoperability (at the moment) > > and basically no use for it in corporate environments (read: with > > Outlook users), thus definitely no high priority for me. Once you > > have > > a feature request filled you can also convince someone to work on > > it > > and provide patches. > > This is off-topic slightly, but isn't letting outlook define the > feature set of evolution like letting IE 6 define the features of > firefox? Hi, I definitely didn't want to sound that way, I swear. My idea behind the mentioning of the Outlook was rather meant to be an example of other client which does not have it (yet), but many people are still using it. The thing is that the current man power on the evolution(-data- server) is very limited, thus it's better to focus on things affecting majority, rather than minority, of the users (that's a subjective measure, I'm sorry). That's the reason why I mentioned that patches are welcome, because I'm not against the idea, I'd only prefer to review patches, than work on it myself. 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] Recent modofication with eds cache (3.25.91)
On Fri, 2017-09-01 at 11:45 +0500, Khurshid Alam wrote: > When I tried evolution 3.25.91, I noticed it doesn't dump online > calendars as ical in ~/.cache/evolution/calendar/ > anymore. Instead it creates a database called "cache.db" in it? > What kind of database is it? Hi, yes, it's an sqlite database. > We, at Credence, so far, have been using a python client to sync > other machines in lan which do not have internet. > We simply pick "calendar.ics" from eds cache and sync it with other > machine using syncevolution. > > This recent change will definitely break our script. Is there any way > you would keep the old behaviour along with new one? No. That would mean double disk storage and/or other complications, which doesn't worth it considering you are touching internal eds files. > Although it is still possible to parse "cache.db" (assuming it's > sqlite), but I do not want to resort to such crude method. You do not need to parse. See the attached script. Run it as: $ cache-to-ics.sh ~/.cache/evolution/calendar//cache.db and it'll create calendar.ics in the current directory containing the data from the cache. The resulting file can have issue with CRLF, but libraries like libical can parse it anyway. > But I would rather use proper backend, but it seems gobject- > introspection bindings for ecal is also missing. I me an there is > binding for ebook but not for ecal. Why is that? It's due to libical, which can be compiled with some introspection bits, but they are not good, especially for older versions of libical. There is a plan to port libecal to use libical-glib instead, which will make introspection for libecal possible and fairly easy. The libical-glib is merged into libical upstream (it begun as a separate project), thus when it's released and distributions pick it and there will be time to dive to such a large change on the eds side (and anything connecting to libecal and/or providing a calendar backend), then the plan will move forward. Bye, Milan cache-to-ics.sh Description: application/shellscript ___ 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] Looking how to contribute to Evolution email client
On Wed, 2017-08-30 at 13:39 -0400, Manny B wrote: > I would like to know how I can contribute to the evolution project. I > have become very interested with the evolution as I love outlook on > windows. Coming to you all to see where I can help. Hello, thank you for your interest in Evolution. You can see some of the information on the Evolution wiki page: https://wiki.gnome.org/Apps/Evolution which contains a subsection for developers: https://wiki.gnome.org/Apps/Evolution#Developer_Resources Please note that Evolution doesn't mean only the evolution project, it depends on evolution-data-server too, thus some changes can mean touching either or both of them. I suggest to search GNOME bugzilla for opened bug reports and pick some. As the subsection for developers shows, there are some bugs marked for new comers, which not necessarily mean they are suitable for them, but it seemed to the developers that they are good to start with for someone not knowing the project much. It's the "easy-to-fix bugs" link on the wiki page. 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] Taskwarrior plugin for evolution
On Tue, 2017-05-23 at 12:22 +0100, Ankur Sinha wrote: > I was wondering if someone could give me a few tips on whether it > would be possible to integrate taskwarrior with evolution's tasks? Hi, you might want to write a Tasks backend for evolution-data-server and a configuration extension for evolution. The closest is probably the Google Tasks backend, which resides here: https://git.gnome.org/browse/evolution-data-server/tree/src/calendar/backends/gtasks while you would need all except the e-gdata-oauth2-authorizer.* files. The configuration extension is here: https://git.gnome.org/browse/evolution/tree/src/modules/cal-config-google/e-cal-config-gtasks.c I suggest to target 3.25.2+ version, thus the current development, where evolution-data-server contains ECalMetaBackend, which hides all the boring stuff about evolution(-data-server) internals and lets you focus on the important parts, like getting events from the server, saving them to the server, remove them, convert from/to iCalendar structures (if needed) and so on [1]. The Google Tasks backend already derives from it. If you'd like to propose it as a feature request and have it included in evolution-data-server and evolution, then I do not see any issue with it. Bye, Milan [1] https://git.gnome.org/browse/evolution-data-server/tree/src/calendar/libedata-cal/e-cal-meta-backend.h?h=wip/offline-cache#n98 ___ 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] Using an ECalObjModType enum as a property
On Thu, 2017-02-09 at 21:51 +0100, Iñigo Martínez wrote:
> g_object_class_install_property (object_class,
> PROP_MOD_TYPE,
> g_param_spec_enum ("mod-type",
> "Modification type",
> "The modification type of the event",
> ECalObjModType,
> E_CAL_OBJ_MOD_THIS,
> G_PARAM_READWRITE));
Hi,
check the documentation of the g_param_spec_enum(), the parameter is
meant to be a GType, but you pass it an enum name instead. The proper
value comes from e-cal-enum-types.h (included through
libecal/libecal.h, in this case E_TYPE_CAL_OBJ_MOD_TYPE.
By the way, why do you want an object property "mod-type"? It's usually
used as a function argument, not much useful as the object property,
from my point of view. Or you use it as some sort of default?
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] Labels when using Evolution EWS
On Sat, 2017-01-07 at 10:56 +0100, Andrew Seguin wrote: > I used your tip regarding the SQL query, it was helpful to get a > clean list of labels as Evolution saw them (which was identical to > how Outlook saw them, but I had forgotten to add a couple). Hi, I made some changes the last Friday for the 3.24.0 Evolution (will be part of the 3.23.4 development release), where the Folder Properties dialog has added a Labels tab, where users can see all available labels as advertised by the server and create/edit/delete the Labels for the evolution as needed. That will avoid the sqlite completely and make it more user friendly. > This leaves me wondering if this is expected or not? What little of > the Evolution-EWS code I read that was closely working with the > labels, I don't see that it should have influenced the case, so - is > it Evolution or the Web services interface Exchange that might be the > one changing the case? As far as I can tell, the evolution-ews sends the labels as they are stored locally, the only change it does is to rename the standard labels [1]. It's the evolution itself lower-casing the tag when creating a new label, for compatibility with the Thunderbird [2]. The added functionality for 3.24.0 doesn't change case of the label tag when creating a new label for an existing tag. Your tests suggest that the Outlook itself treats Categories (the EWS name for the Labels) case insensitively, only the Outlook Web Access (OWA) interface treats it wrong. I'd say it's a bug in the OWA. Evolution itself also treats label tags case insensitively. Bye, Milan [1] https://git.gnome.org/browse/evolution-ews/tree/src/camel/camel-ews-utils.c#n381 [2] https://git.gnome.org/browse/evolution/tree/src/mail/e-mail-label-list-store.c#n77 ___ 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] Labels when using Evolution EWS
On Thu, 2017-01-05 at 15:55 +0100, Andrew Seguin wrote: > I tried creating labels in Evolution with the same names as those > used in Outlook, without any difference in Behavior. Hi, right, that's the way it works. The Labels column in the message list shows only those labels which are known to the evolution. There is currently no way to show all known labels, or which are set up on a particular message, in the UI. Going very low level, as you indicated that you can read the code, search your ~/.cache/evolution/mail/ folder for the one which contains a folder-tree file, that's for your EWS account. Beside this folder-tree file is a folders.db file, where is stored the information you can see in the message list, including the labels. Open this folders.db file and check what the 'labels' column in respective tables contain. You can do also something like: $ sqlite3 folders.db "SELECT labels FROM inbox WHERE labels NOT LIKE ''" The labels are separated by a space. Once you've defined the same in the evolution then it should start to recognize them. There are issues with encoding and spaces/underscores, though your examples seem to be simple ASCII letters only. Hope it helps, 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] ? change in how delayed send functions ?
On Mon, 2016-12-05 at 21:08 +, Reid Thompson wrote: > Was this change intentional? Hi, nope, it's a bug. Please file it in GNOME's bugzilla. Right-clicking the Outbox folder and picking "Flush Outbox" still works. 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] Head-up: Evolution-Data-Server Camel API changes to land next week
On Mon, 2016-10-31 at 20:43 +, Zisu Andrei wrote: > I had some patches for the SPECIAL-USE flags, but I haven't had time > to deal with them over summer, should I also try to get those merged > before the window closed? Hi, I suppose you mean https://bugzilla.gnome.org/show_bug.cgi?id=767821 It'll be nice to have that part of 3.23.2, yes. If I recall correctly, the current aim is to not change current API, only add new symbols (without a need for the migration), which won't need a soname version bump ideally. It's still a 3.23.x material. Thus if you have time, please update the patch at that bug report and we can continue there. 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] Switching from Autotools to CMake for core evolution products
On Thu, 2016-10-27 at 18:10 +0100, Sam Thursfield wrote: > On Thu, Oct 27, 2016 at 3:23 PM, 藍挺瑋 <lant...@gmail.com> wrote: > > 於 週三，2016-10-05 於 09:33 +0200，Milan Crha 提到： > > Can we have a common way to enable GTK-Doc installation in modules > > using CMake? In modules using Autotools, we have --enable-gtk-doc > > which is recognized by every module supporting generating > > documentation with GTK-Doc . However, we have two important modules > > using CMake, Evolution (including Evolution-Data-Server) and > > WebKitGTK+, but they require different options to enable GTK-Doc. Hi, I agree that the consistency is "good to have". I chose the name to stay as close to the one from autotools as possible. Similarly with other offered configure options. > gtk-doc now ships a CMake module upstream: > <https://git.gnome.org/browse/gtk-doc/tree/cmake>. > > I adapted this from existing code in the Firtree project: > <https://github.com/rjw57/firtree/tree/master/cmake/Modules> > > It would be nice if Evo and WebKitGTK+ could switch to using that. It > may need some improvements; I used it successfully in a couple of > projects (proprietary ones, sadly) but I don't know how much use it > has had elsewhere. Unfortunately, I do not recall what failed for me when I tried to use it in the time I've been adding the functionality into the libical. It's couple months ago, it's likely that the things changed on the GtkDoc side meanwhile, I really didn't give it a try any time recently. Similarly to WebKit, I currently do not plan to bump GtkDoc dependency, but it doesn't mean I'm against it. As I begun above, the consistency is good to have. 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] Documentation Issue? Leaving messages on server indefinitely
On Thu, 2016-10-27 at 20:10 +0200, Mario Wenzel wrote: > Sadly the documentation doesn't state whether this is possible. If it > isn't, then this is basically a feature request and I'll file it as > one. If I can just set 0, I'll file it as a documentation issue. I > don't know which. Hi, the "Delete after [ 0 ] day(s)" works like "Leave messages on the server forever". I use it here too. By the way, you would get sooner response, if you write to the evolution-list. Your question is user centric, from my point of view, thus it would make perfect sense to ask the users, whom would know too. 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] Feature request: filter out messages from known senders
On Tue, 2016-10-25 at 21:23 +0200, Jarek wrote: > I'd like to have a filter condition, selecting messages from > senders from address book. > I'd like to create folder for unknown senders. Hi, that might be pretty slow, at least according to the past experience, where a similar thing is done with "Load remote content only for messages from contacts". This feature did cause slowness. I cannot imagine that the rule would check all the senders in my mailing list folder which currently has more that 162.000 messages (not unique senders, luckily). Imagine you've like 10.000 different senders, that would be a flood on the address books lookup. Count to it remote address books, like WebDAV, Exchange, and so on. I even do not want to think of the consequences when the search folder would be updated due to whatever reason. In other words, the performance would be the main problem. By the way, this list is not meant to be used for feature requests, there is the GNOME bugzilla for it: https://bugzilla.gnome.org/enter_bug.cgi?product=evolution 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] contacts sync from eds to idevice.
On Thu, 2016-10-13 at 09:36 +1100, Timothy Ward wrote: > The updated gtk3 eds-to-idevice code is on github at > > https://github.com/gitsop01/eds-to-idevice > Any advise on the idea or code or what would be required to > have it included in eds as a sync backend to an idevice would be > appreciated. Hi, okay, so I opened the github page and checked the configure.ac and it claims at the end these dependencies: libimobiledevice-1.0 libplist glib-2.0 gtk+-3.0 The glib-2.0 is no problem, it's used by the evolution-data-server (eds). The gtk+ is an optional dependency for the eds. The other two libraries are completely new for the eds. You said it's a command line tool, which makes me wonder why you want a gtk+, when the command line is meant to run without any display. As you claimed that to have full functionality the build requires some recent code from the github (maybe unreleased?), then I hesitate to take this into such core GNOME product as eds is. It could be included, but disabled by default, which degrades its usage heavily (the packagers would not notice it exists, when it'll be disabled by default). The other part of the deal would be the maintenance of the code. I'm surely not able to give any maintenance to the code, I even cannot test whether it does what it is supposed to do, because of missing any Apple device here. In that case, who will take care of the code? And for how long? This is nothing personal, we do not know each other, I've just pretty bad experience in this regard; people promised me many things to get where they wanted to be, but then forgot of the deal quite quickly afterwards. 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] contacts sync from eds to idevice.
On Thu, 2016-10-13 at 05:06 +1100, Timothy Ward wrote: > gtk3 eds-to-idevice code exists to sync contact information between > eds and an idevice. It is coded as a commandline utility at the > moment, and was a git project that I updated earlier this year > from the original author. > > As evolution does not have the capability at the moment > to sync contacts to an idevice, I was wondering if this would be > a worthwhile project to add to evolution. Hi, it sounds interesting. I'm wondering, is it anything what for example syncevolution [1] cannot do? I understand the syncevolution as a pretty complete solution to move contacts/event/memos/tasks between the evolution-data-server and the servers (and/or devices, if I'm not mistaken). That is, maybe it'll make more sense to include it there, to have all of such functionality at one place. That doesn't mean it couldn't be part of the evolution-data-server, I'm only unsure how to test and maintain the code, because I do not have any idevice (or I do, but I'm not aware of it; it depends what you understand behind that name). By the way, what would be the new dependencies to be able to compile your code? Thanks and bye, Milan [1] https://syncevolution.org/ ___ 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] Switching from Autotools to CMake for core evolution products
On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote: > I plan to merge the changes the next Monday, October 10th, some time > after the 3.22.1 release. This way there will be enough time to catch > any issues before the 3.23.1 release. Hi, this is a notice that the changes had been committed to git master of the modules and some after-commit fixes had been done as well already. 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] Switching from Autotools to CMake for core evolution products
On Wed, 2016-10-05 at 12:28 +0100, Philip Withnall wrote: > Out of interest, why? Hi, seems to be better than autotools, gives more freedom and easily allows the sources to be built much faster than with autotools (it builds here in ~1/3 of the time which uses autotools, still using "Unix Makefiles"). I know it's caused mostly by not having one giant Makefile.am, but this way it's easier (at least for me). With the "gives more freedom" I think of different generators, which CMake offers quite many [1]. Bye, Milan [1] https://cmake.org/cmake/help/v3.6/manual/cmake-generators.7.html Note it's for version 3.6, while the required CMake version is 3.0 ___ 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] Switching from Autotools to CMake for core evolution products
Hello, this is a heads up that the evolution-data-server, evolution, evolution-ews and evolution-mapi products will switch from Autotools to CMake for the 3.23.1 release. Each of them has created a wip/cmake branch, which builds and even runs. I tried to keep things as close as they were with the Autotools, but I made some cleanup changes here and there (the evolution installs more shared libraries, evolution-ews and evolution-mapi have some installed libraries renamed and/or added; header and pkg-config files for the evolution-ews and evolution-mapi are not provided any more), thus some tweaks in packaging (apart of calling CMake instead of autotools) will be required. The build with CMake is straightforward, if you already got in touch with it. Similar to Autotools, if some feature is enabled and its dependency cannot be found, then an error is printed with a notice how to disable the feature if needed. At the end of the configuration phase are printed all the available options which can be used to tweak the builds, to both know with what options the project had been configured and to know what options are available in general. I plan to merge the changes the next Monday, October 10th, some time after the 3.22.1 release. This way there will be enough time to catch any issues before the 3.23.1 release. I also plan to clean up the source tree a bit, like adding src/ directory into the evolution-data-server and evolution, but I do not expect it would have any impact on the installed bits. Any custom distribution patches would need update, of course. I may do some other miscellaneous changes here and there before and after the merge as needed. You can give a try to it already with a snapshot of the wip/cmake branches [1], if you'd like to. I'd prefer to hear about any issues on the evolution-hackers@gnome.org list only (I'm not subscribed on the distributor-list, but on the other two lists I am). Thanks and bye, Milan [1] https://git.gnome.org/browse/evolution-data-server/snapshot/evolution-data-server-wip/cmake.tar.xz https://git.gnome.org/browse/evolution/snapshot/evolution-wip/cmake.tar.xz https://git.gnome.org/browse/evolution-ews/snapshot/evolution-ews-wip/cmake.tar.xz https://git.gnome.org/browse/evolution-mapi/snapshot/evolution-mapi-wip/cmake.tar.xz ___ 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] Evolution display width too large
On Tue, 2016-10-04 at 14:46 +0200, Tom wrote: > sorry for cross posting (if it really is) but I have two addresses > for the hackers stored here. Hi, I noticed your query on the evolution-list [1], where Andre already replied to it. I can extend his explanation, if you prefer, but I'll rather do it there, to not reference the two threads between mailing lists. Bye, Milan [1] https://mail.gnome.org/archives/evolution-list/2016-October/msg00022.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] Heads-up: Evolution-Data-Server and Evolution to depend on WebKit2 since 3.21.90
Hello all, this is just a little heads-up that the evolution-data-server's libedataserverui sub-library and the evolution itself will depend on WebKit2 since the upcoming 3.21.90 release, unless anything really bad would rise till the release Monday. Big kudos to Tomas Popela, whom led this effort. Anything what links against libedataserverui or the evolution libraries should not use WebKit1, only WebKit2 (or no WebKit, of course), because these two cannot be mixed in runtime. That was the reason why the evolution-data-server wasn't ported yet, because the evolution was still using WebKit1 and it links against libedataserverui. The evolution-data-server dependency on WebKit is optional, it can be avoided in the configure time by using --disable-google-auth configure option, though it's better to have the option enabled, because it adds some functionality for the evolution and other clients of the evolution-data-server. 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] Thread-conversation view
On Fri, 2016-07-22 at 09:54 +0200, Éloi Rivard wrote: > I am curious of your interest in the thread-conversation view > (#258233), that appears in the evolution TODOs. Is there any plan to > work on it soon, or is there any blockers that prevents you to? Hi, mostly lack of time (more important things to be done) and lack of man power is blocking any such enhancement requests. Patches are always welcome, of course, thus if you find anyone willing to spend a time on it, then it'll be great. Just attach the patch into the bug report you gave a link to and wait for the review. 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] help me!!
On Wed, 2016-05-11 at 14:50 -0400, Ronny Montano Martinez wrote: > Hello, I write because I am developing an application in Python. Here > I need to add new events to the calendar application evolution, but > will not let me, when I try to import or ECalClient ECal displays a > message in error, I hope your help as soon as possible, thanks Hello, I would like to help, but you didn't give enough information to be able to do that. Could you clarify these things first, please? a) what is the exact version of the evolution-data-server and evolution you are using b) do you want to add the event from the python code, or from the evolution itself c) where, in which calendar, do you want to import the event d) what is the exact error message you receive; if you run evolution in a non-English locale, then ideally run it as: $ LANG=C evolution Also check the evolution console, whether it shows anything useful. It can be that the background processes will claim errors in the other locale, thus you might want to run it similarly: $ LANG=C /usr/libexec/evolution-calendar-factory -w and only then run the evolution from another terminal. The exact location of the calendar factory executable depends on the distribution you are using. e) could you share a test event you are trying to import, which fails 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] [PATCH] evolution-data-server: the language for the day of the week in quoted messages should match the message language
On Fri, 2016-04-15 at 17:07 +0200, Guido Trentalancia wrote: > When quoting a message in a reply, make sure that the language for the > day of the week matches the language of the quoting text generated by > evolution. > Hi, please, do not send patches here, the team uses GNOME bugzilla for this purpose. You already have opened a bug for this [1], thus please stick with it. It's time consuming even for you, doing all the work twice, once here and one in the bugzilla. Thanks and bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=765112 ___ 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] vCard test suite
On Tue, 2016-04-05 at 20:44 +0200, Ángel González wrote: > On 2016-04-05 at 08:52 +0100, Philip Withnall wrote: > > I don’t think I explained clearly enough, sorry. All three options > > are > > proposing to keep vcard-test-suite as a separate project, which EDS > > depends on in some way (either as a test-time dependency, a git > > submodule, or a build-time dependency). > > I don't think it should be a build-time dependency. If the dependency > is not fulfilled, you should still be able to build and run eds > (except > for running those tests, of course). > Hi, I agree with Ángel, build time dependency is out of question. Also because soft dependencies are easy to overlook, thus one might easily not even notice the new test suit. I'm not sure how you'd like to have done the test-time dependency. If the files would not be available, will the whole test suit be skipped, or the test will fail with an error? The first option is similar to build time dependency (being it a soft dependency). The second option might be a bit limiting, no? That lefts us with a git submodule. What is the difference between the git submodule and direct inclusion in the sources? If you want to cover more than vCard tests for the evolution-data-server (like testing also other vCard parsers, from other libraries), then it seems to me that the cleanest solution would be to provide installed-tests from the git repo as you have it, just define different "targets". I mean, I miss a gain in the inclusion of the project as a git submodule in the evolution-data-server. It's possible I'm overlooking something though. 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] vCard test suite
On Sun, 2016-04-03 at 22:13 +0100, Philip Withnall wrote: > How would it be best to include this in the EDS test suite? The > options > I see are: > • Install the vCards on the system in the installed-tests prefix, > for > use by unit tests installed by EDS. > • Import them as a git submodule into EDS. > • Keep vcard-test-suite separate and have it install its own unit > test > for EDS[1]. > > I think the first option might be the best, but I would appreciate > others’ input. > Hi, if the Collabora is fine to copy/move the data and the code in the evolution-data-server sources, then I do not see any issue with it. I would also prefer to make it part of the installed-tests for the evolution-data-server, together with the binary which will process all those files (install data and do not use them looks incorrect). The source code for that binary needs a little coding-style changes to conform the style being used in the evolution-data-server, but that's only a minor things (apart of the "blah" string there). 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] Making an email-moving plugin
On Sun, 2016-04-03 at 22:28 +0200, Ángel González wrote: > Where should I begin dealing with it? I have looked at those at the > plugins folder, but none of them seem to do any of the steps I need. Hi, the plugins are sort of an outdated technology in the code, what you want to do is an EExtension, which are stored in modules/ directory. You read the CamelFolder and the set of selected messages from an EMailReader, then you do whatever you want using the CamelFolder API. In your case of moving the messages between folders you call camel_folder_transfer_messages_to() or its _sync() variant. You might want to read the messages first too, to check the headers, which you can do using camel_folder_get_message(). One of the close changes, regarding message move to other folder, was done in this [1] commit. You might be interested in the .ui file changes and in the e-mail-reader.c changes. It is not a module, it's inside the code, but it shows at least how to easily move messages between folders and how to get to the list of selected messages. I do not know which evolution version you target this for, but also consider using e_shell_view_submit_thread_job(), which helps to run jobs asynchronously and reports errors to UI, together with a possible feedback and cancellation capabilities (the used cancallable is a CamelOperation, through which you can pass the feedback and progress). With respect of what to extend, one possible type is a MessageList, though you cannot get directly to the EMailReader from it. You can use an EMailBrowser type as the extensible target, which is the separate window showing the message (it also implements the EMailReader interface), and also EMailPanedView type, which is the one in the Mail view. You can extend also other types and add your UI elements into the EMailReader related parts (like shown in [1]), and all of that will be propagated to all EMailReader descendants/implementations, without you knowing whom they are at all. Hope it helps, Milan [1] https://git.gnome.org/browse/evolution/commit/?id=f6c0c822 ___ 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] EClient Functions
On Mon, 2016-03-28 at 07:33 +1100, Timothy Ward wrote: > The EbookClient functions such as: > > 1) e_book_client_connect_sync and > 2) e_book_client_connect_direct_sync etc > > are Declared as EClient * functions but return an EbookClient > > Does this means that the returned EbookClient must be type casted to > a EbookClient to stop the Compliler warnings about the mismatch in > declaration of the function and what the function returns. or am I > missing the point here. Hi, to be honest, I do not know why it is done this way. Maybe for a similarity with gtk+, where the "new" functions also return GtkWidget, not the respective type the function created. > What is the correct code to type cast for an EbookClient. It depends on your language. If it's C, then: EBookClient *book_client; EClient *client; client = ...; /* check for errors and such (for example client can be NULL) */ ... book_client = E_BOOK_CLIENT (client); That's pretty common way of doing these things with GLib. > When using these functions with evolution-data-server can a new glib > main loop be started for bdus operation or does it have to started > in another way for an application that wishes to retrieve all contact > info for the available addressbooks. A good example is gnome- > contacts. Check the backtrace, there is a book_client_dbus_thread() thread which is for D-Bus things about the EBookClient. In any case, whenever you call a ..._sync() function, you should know that such function can block and thus eventually freeze the application if it's run in the main (GUI) thread. Either use the asynchronous variants of the functions or run your own thread where you'll do the synchronous calls, possibly incorporating structures like GTask. > > 1) Is the only two methods of getting all contacts fields in an > EWSaddressbook is either to iterate over a list or hash table of > all known fields of a contact, or > > 2) Use the vcard functions to get all the known fields. This has not much to do with the EWS backend, the EBookClient tries to not expose where exactly you get the data from, it gives you the data in the same way for any backend. If you want to get the information from the EContact, which is the descendant of EVCard, then you can: 1) have a list of all possible fields in the EVCard and check whether your EContact contains them 2) ask the EBookClient for supported fields and check only for those 3) finally, if you care of performance, then use the EVCard functions to get list of actually stored attributes on the EContact and use only those you know about. Do not feel confused to use EVCard functions, the EContact provides only a "proxy" structure which makes it easier to work with certain attributes, by internally calling EVCard functions anyway. Hope it helps, 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] Account autoconfiguration/autodiscover
On Tue, 2016-03-01 at 09:22 +0100, Tobias Mueller wrote: > Hm. GSoC is 12 weeks or so. And the intern would probably be > completely unaware of Evolution's codebase. Do you think that's > feasible, still? Hi, I'd be afraid a bit. See below. > How about a separate tool that will then set up your evolution > accounts..? The only difference would be that you run a separate application, instead of an integrated tool within the application. Thus the way you call the "function". All the rest would be the same. Thus no win to write a separate application, instead of a built-in code. Of course, it can start as a separate application, but would end in the evolution code base anyway. > Could anybody mentor such a project at all? I guess so, but honestly, the current main priority for 3.22 is to port evolution to webkit2. It's a huge change and I expect some fallouts of it. I could be a mentor, but I cannot promise a full focus on it, which it might need. Thus I'd prefer to postpone the work on the autodiscover. I also have other things which I'd like to do before it, which I have in my todo pile longer that this. Maybe the webkit2 port will not be a big issue, but I prefer to not have tight schedules and so on. 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] Account autoconfiguration/autodiscover
On Wed, 2016-02-24 at 10:34 +0100, Tobias Mueller wrote: > Do you think it would be something for the upcoming Summer of Code or > Outreachy rounds? Hi, it depends. It's not a large change, but not a tiny too. It also depends how one would solve this. My not so simple idea on this is: a) using File->New->Mail Account to create "corporate-like" accounts doesn't feel right, even the addons like evolution-ews and evolution-mapi do that b) a better option would be to add a new Edit->Server Accounts (the wording is awful, I know), where you fill only User name and E-Mail (or server domain, if not email), and then the wizard will check what that domain offers based on the SVR records, well-known HTTPs entry points and so on and offers to add all sources it'll find for the user, thus you gen not only Mail, but also Contacts, Calendar, Memos and Tasks, if the server supports it. Furthermore, users will be able to manage which sources should be visible in the UI (offered to other evolution-data-server clients) here, not like it is done currently, where you get all or nothing. Having a working prototype would not be that hard, but fine tune it will be harder. Part of the fine-tuning will be also the extensibility of the new Server Account dialog, to be able to attach custom autodiscovery methods to it. 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] Account autoconfiguration/autodiscover
On Wed, 2016-02-24 at 08:51 +0100, Narcis Garcia wrote: > I have many users with Evolution 3.10.4 in Ubuntu 14.04 Hi, the current Evolution (also the development version 3.19.90) doesn't support any kind of this autodiscover thing for mail accounts. The settings lookup is read from static tables on a GNOME server. On the other hand, you can prepare set of .source files, located at ~/.config/evolution/sources with preconfigured settings and distribute these to your users. I know it's not the same, but it can help to admins, at least a bit. The only piece software which uses some autodiscovery is evolution-ews (eventually also evolution-activesync), but that is strictly used for Microsoft Exchange servers, not for any random. Similar things had been discussed recently. Related bug reports in GNOME's bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=640598 https://bugzilla.gnome.org/show_bug.cgi?id=720603 https://bugzilla.gnome.org/show_bug.cgi?id=750564 If you could create a new bug report (or find an existing) and add there a reference to any developer documentation which describes how your server autodiscover settings exactly work, then it can be added to the pool of these bugs. 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
