Re: [Evolution] Starting Evolution from backup
- From: Milan Crha <mcrha redhat com>
- To: evolution-list gnome org
- Subject: Re: [Evolution] Starting Evolution from backup
- Date: Wed, 11 Jul 2018 21:48:08 +0200
On Wed, 2018-07-11 at 12:25 -0700, Douglas Summers wrote:
it ran well, but I like how
the "native" package integrates with the desktop.
Hi,
yes, I fully understand that and agree with you, but in case of
evolution, and its dependency on evolution-data-server, there is no
win-win state, I'm sorry. Either you run up-to-date evolution against
possibly long ago obsolete evolution-data-server D-Bus services and you
have the fancy integration with the desktop and have access to local
disk and such, or you run really up to date evolution and up to date
evolution-data-server, thus you really get all the latest fixes [1],
but you run in a sandbox, with no integration with the desktop, no
notifications, no local file system,...
It's a pita that Flatpak itself doesn't have something in between of
"talks-to" and "owns" for D-Bus interfaces, in which case one would be
able to override some D-Bus services, but keep using other system's
D-Bus services. That would be a killer feature of Flatpak, from my
point of view, but as long as this is relevant only for a minority of
the Flatpak applications, and most of them even "do not care" (no
offense meant, they target something else), then it makes sense Flatpak
developers also use their time on other issues and features. To be
honest, I do not know whether it's possible at all, the obstacle can be
somewhere else than in Flatpak, maybe it's in D-Bus itself, I really do
not know.
Bye,
Milan
[1] One example for all: like with the timezone thing in EWS, the
change for I#7 https://gitlab.gnome.org/GNOME/evolution-ews/issues/7
had been done for the evolution-data-server side, namely for a backend
which runs in evolution-calendar-factory(-subprocess). Having a Flatpak
version of evolution which integrates with the desktop, then even if
you build that Flatpak version against the latest evolution-ews, then
it'll still talk to the old and unpatched evolution-calendar-factory in
your system, thus you'd not have the issue fixed. This is sometimes
hard to realize.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]