On Monday, December 10, 2018 2:51 PM, Jonas Ådahl <[email protected]> wrote: > There is an alternative more generic solution to this problem, and all > other related to what XSettings did in the past. If we'd end up > introducing a protocol like this, we might end up with many tiny > protocols for things previously covered by XSettings. Cursor things, > font things, and what not. Adding a new protocol for each these things > would be silly. > > The generic alternative is designed with sandboxing in mind (but > of course doesn't require it in any way), and is part of > xdg-desktop-portal, the same place where the compositor agnostic > screen casting API lives (org.freedesktop.portal.ScreenCast, implemented > at least by GNOME and KDE). > > It's a D-Bus API called org.freedesktop.portal.Settings[0]. The only > thing a compositor would need to do is to provide a > org.freedesktop.impl.portal.Settings implementation using whatever > settings backend might be in place.
Hi, Unfortunately I don't think D-Bus is a good solution here. Here are a few reasons why: * Not all clients use D-Bus. Adding support for your API would mean adding a lot of code and new dependencies to many clients. * The idea would be to add support to libwayland-cursor so that many users can benefit from the protocol. I don't think firing up a D-Bus connection in libwayland-cursor as a viable solution. * Multi-seat support would be kind of alien. What do you think? Thanks, Simon > > Jonas > > > [0] > https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Settings.xml _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
