[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
