On Wed, 2017-07-19 at 12:20 -0400, Owen Taylor wrote: > ...and there would have to be some plan that would work when the > desktop doesn't include EDS (what if you are running on > KDE?) Would the flatpak runtime include a simple implementation? Hi, there is no such thing like "simple implementation", if you mean evolution-data-server. And even you highlight Evolution, it's not about it. It's about evolution-data-server, which serves as a data storage for Evolution, GNOME Contacts, GNOME Calendar, GNOME To Do, GNOME Shell, bijiben, geary and so on. The evolution-data-server is a hard dependency for these. When you run an application which needs any of the services provided by evolution-data-server, regardless which desktop environment you are running, then the services are run on demand. Transparently. No problem with it. The nice thing with the current RPM is that all the data is shared between all those applications, thus you can check your calendars both in Evolution and GNOME Calendar, without a need to configure them separately to know about the same calendars. Similarly for other products. And count to it also GNOME Online Accounts, as a central place to define accounts, which can be picked by various applications. That's an advantage and had been advertised as such when GOA became alive. Such advantage should stay in place once you'd like to provide GUI applications as Flatpak in Fedora. If I understood it properly, then you suggest that these sharing will be impossible in Flatpak delivered GUI applications. That feels like a regression, at least to me. It's nice that there is used GNOME Recipes as a "proof of concept" when it's used as a Flatpak-only delivery in Fedora 26, but it's no real GUI application, it has no real dependencies. You might use "nano" for the same "proof of concept". The worse that the plan is to have all GUI applications delivered as Flatpak. You might pick something more complicated, what actually uses core system services to deliver certain value to users, to have the proof of concept. Otherwise you have "this works for this Fedora and no where else". From my point of view. On the other hand, if GUI applications delivered as Flatpak in Fedora are meant for certain version of Fedora, then it's all fine. In that case the Flatpak would not be meant as a generic runable package on any distribution, only on that certain Fedora. It would be different when trying latest stable/development version of the GUI application on an outdated Linux. It is expected to not have that data sharing advantage there, from my point of view. But on the other hand, such Flatpaks would be provided by the upstream, not by Fedora. I briefly looked into the Flatpak build script for GNOME Calendar [1] and it builds its own evolution-data-server. At least the upstream version. It makes sense. If I would create a Flatpak for Evolution, then I'll do the same. Might or might not it be done in Fedora too, when built from rpm? > I don't think bundling GNOME Online Accounts makes sense - it appears > like part of the desktop to the user. In the unsandboxed case, you > can just access the D-Bus service from your application. Evolution-data-server links to it and it's a soft build-time dependency. No D-Bus hacking, just using provided C API by GOA. > We definitely don't want debugging Flatpak applications to be no fun! Ah, great, then I've been misinformed. I'm sorry about that. Thanks and bye, Milan [1] https://git.gnome.org/browse/gnome-calendar/tree/org.gnome.Calendar.json?id=d0787df33030b4b8b8b78da79873b4556f772937#n59 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
