Budgie portal backend implementation #428
Replies: 6 comments 1 reply
-
Thanks for the proposal on the Budgie portal backend implementation. I'm going to be breaking down my line-of-thinking on the portal into two phases, one being Budgie 10 and the other being Budgie 11, since they are fundamentally different. We should try to keep that in mind as work is done on any portal implementation, of course recognizing some of it will need to be rewritten for 11 anyways and that is unavoidable. Budgie 10 ContextAs you mentioned, Budgie 10 will still be relying on some parts of the GNOME stack even after Magpie v1.0 is released. Specifically, I anticipate that we will be relying on (that are of relevance to this discussion anyways):
Budgie 10, at the point in time when it is leveraging Magpie v1, will be in a bit of an odd place. We will be effectively starting to walk out the door on the GNOME stack, but will for all intents and purposes be basically "Budgie 10 + Wayland + some new config bits". It will be a mess, there is no point in mincing words on it, but it is what it is. Budgie 10We will still be using GTK within Budgie 10 series and therefore any portals should, within reason (definition of that still needs discussion), support GNOME settings and desktop schemas, in conjunction with any agreed upon configuration that could be separate from the GNOME stack. By that I mean we could have already agreed on the configuration that would be consumable by Budgie 10 and Budgie 11 carried forward for the various portal bits and simply lob off the GNOME support come Budgie 11. If we anticipate some settings will be fundamentally incompatible with the goals / ideas of GNOME on it, then priority should be given to a singular implementation / integration point (ours over GNOME). WaylandMagpie v1. Not much to comment on there yet. Configuration & Language ChoicePlanI will be starting work on Budgie Settings Daemon within Q3. This will be the heart of Budgie 11 but will already have integration points with Magpie before 11's development begins. LanguageI was originally planning on writing this in Rust, however as the team continues its internal discussions and exploration of viable alternatives to GTK, it is more likely that given the current landscape and changes in it, we will be using C++ for Budgie 11. It's something I'm actively relearning, since it's been uhh...so anyways let's not count the years..., and so far frankly I prefer it over Rust. So it's quite likely B-S-D will be written in C++. As such, Magpie would basically be the odd one out when looking at the midway point between 10 and 11, as it is written in C unless @serebit opts to do some of the frontwork required to get C++ to play nicely with wlroots, similar to the work done by "that one tiling window manager that I don't want to name". If the portal was written in Rust, things would start to get pretty inconsistent, with us using: C, C++, Rust, and Vala. The Vala stuff will die in a fire with Budgie 11, but I'd really like us to centralize around one or two languages. Realistically I think that'll be C and C++, with C++ having less footguns over C (but more over Rust). Yes, I know there are Rust bindings and projects always in the works like CXX + CXX-Qt, I'm just yet to be convinced that it is in a manner which is ergonomic (a personal preference over absolute safety) rather than feeling like you are shoehorning languages into each other -- especially for stuff like Qt and QObject. So tldr of that blob of text is: I'm not opposed to it being Rust, what I am opposed to is increasing fragmentation and difficulty for the team to iterate on solutions long term. Budgie Desktop development was bitten before by the promise of "use X language, get more contributors" when there has either been a lack of that, or it's hurt us long term as we have been saddled with technical debt that isn't even in our preferred languages. As excited as I am by having a significant contribution of the portal, I don't want to be saddled with technical language debt for something that might end up being the "third wheel". Nobody likes being the third wheel. MessagingB-S-D will be using Protocol Buffers (likely with gRPC) instead of DBus for process communication between B-S-D, Magpie, Budgie Desktop, Budgie Control Center, and more. It will have support for DBus but only really for external communication (example: MPRIS support from a media player -> B-S-D -> translate to Protobuf to Budgie Desktop). The Protobuf part is less relevant to Budgie Desktop for 10 series and more relevant for 11, I expect there will be some degree of DBus support for Budgie Desktop to B-S-D. ConfigurationIn the context of Budgie 10, my first priority with B-S-D is development of the configuration system. This same configuration system (config itself may differ) will carry forward into Budgie 11. It'll use tomlc11. Configuration will be file-based and using TOML to:
Magpie v1 will use B-S-D for configuration. It would be preferred that the portal interface with this configuration system directly. This will be required eventually but not a hard requirement to get started IMO, focus can be given to GNOME interop for B10 bits first as far as I care. I just want the end goal to be known is all. Budgie 11 ContextI promise this will be a shorter blob of text. In the context of Budgie 11 and as I have sorta gotten into before, we will have separated from the GNOME stack. You know it, I know it, everybody knows it. The sooner we are off this ride, the better. What ride are we on next? Who the hell knows at this point. The ecosystem is changing underneath our feet, solutions we originally planned on using are basically dead and incompatible with our Wayland only vision (or many of the Wayland protocols in the first place) and the ecosystem has basically coaleseced around GTK (nope), Qt, slint, and iced (which at this point is just starting to feel like System76's own libadwaita). For the portal, no matter how we go about implementing it, there will come a point where the GNOME support will be removed. This should be as minimally invasive as possible, with even separations of "sub-backends" like "legacy" and "11". Legacy would interop with GNOME where desired, 11 for items in 11 or targeting 11, and configuration would be separate (gsettings vs TOML + B-S-D). Languages should be down to two. Whether that is C and C++ or C++ and Rust. Personal preference and expressed concerns in Language section of B10, but discussions welcome on that since it's a decision the team needs to weigh given historical context, other's preferences / views on risk, etc. General Thoughts on InteropFocus should be given towards alignment and engagement with KDE. They are more aligned with us on configuration, personalization, extensibility, etc. Whether it's a distributor of Budgie Desktop, ISV developing integration points for Budgie Desktop, or end users -- the goal for Budgie is to be a platform and not a product. This will result in the risk of inconsistencies in the user experience but it is not a risk I am adverse to, as I would prefer to give the above mentioned parties, including ourselves, the capability to curate their own experiences. Every decision we make for the portal, our engagement on specs, and development of Budgie 11 must be designed with this in mind. If any component of it does not, it is fundamentally incompatible with the vision for Budgie Desktop and not something I approve of. The discussions on this should be framed on how we support or engage with existing and proposed standards, and how we make sure portal development is compatible with the vision of Budgie Desktop as a platform. Yes, it will require more work, but if that opens the door to a more flexible Budgie then that is the obvious choice. Thoughts on Portals discussed in OPAccess, Account, AppChooser Seems fine, no comments. Background We have Autostart support in Budgie Desktop Settings. Background apps are kinda whatever, most expose a system tray which we supported via XEmbed and nowadays Status Notifier anyways. Applications like QOwnNotes that can "start in background" but create a system tray work perfectly fine as is. I know GNOME does some stuff because they are yet to come to their senses about system trays. Yep should just fire up default app. FileChooser User and vendor preference on this should be a configuration option, with those options being file managers that would support the spec, then I imagine fallback to generic file picker for a given toolkit (initially GTK for B10)? GlobalShortcuts Clarification of usecase for this would be nice. Is my understanding corret that we talking about flatpaked applications like OBS Studio getting their shortcuts exposes outside the portal? Seems good to me if so. Inhibit Yea pretty obvious one :D Oh god not printers dies ScreenCast, Screenshot, RemoteDesktop, InputCapture I would say RemoteDesktop is very low on totem pole. Settings See topic on Configuration. |
Beta Was this translation helpful? Give feedback.
-
As per discussion on Matrix, Magpie will be moving from C to C++ to reduce language fragmentation, allowing other components to be written in Rust if desired. |
Beta Was this translation helpful? Give feedback.
-
I'd appreciate it if all anyone had to worry about was The New™. Budgie 10 would be something maintained in a separate branch, and 11 can do all the changes it likes. I'm not sure if I'd like to deal with the cursed GNOME interop here.
I could definitely make this new portal work in the GNOME-based environment, at least partially. Anything not facing the user, like the Settings portal, can be exposed just fine. Stuff that gets into making a UI is a bit nasty, sadly. The GNOME infra can be used for GNOME settings and schemas. |
Beta Was this translation helpful? Give feedback.
-
This seems doable, so long as there are decent libraries available for it in C++ and Rust. The brunt of the DBus communication would be on the portal side of things anyways.
The portal can definitely interact with B-S-D for reading the appropriate settings, like accent colors; it would also be easier than interacting with anything else. |
Beta Was this translation helpful? Give feedback.
-
A (possibly full) redesign may be necessary to properly support the Background portal. At least on GNOME, it basically is the system tray; you can close apps from it, reopen them, and see what's running. The current system tray specs are kind of redundant here, and are kinda bad, and break if you aren't using a Linux system from more than 2-3 years ago.
The GTK portal will always be the fallback, but Budgie should promote a certain file chooser that supports this spec for those that just don't care to pick and choose. We wouldn't want the GTK portal being used in a standard Budgie environment, after all.
It is used for all applications on Wayland that would like to use hotkeys, and most portals here are useful outside of Flatpak too; they're used for general system integration as well. e.g. the FileChooser portal isn't just for sandboxed file access, it integrates well with your environment. |
Beta Was this translation helpful? Give feedback.
-
We'd need everything that RemoteDesktop contains, specifically ScreenCast and InputCapture, for things like a Barrier/Synergy setup too. The main problem there is how wlroots wants to do this; Emersion wants a Wayland protocol, but there's nothing right now afaict, so @serebit might have to implement it directly, as a standard compositor might do. We should aim to implement the RemoteDesktop portal, as it would make things complete and set up everything for e.g. an accessibility portal. |
Beta Was this translation helpful? Give feedback.
-
Currently, Budgie relies on GNOME infra - Mutter, xdg-desktop-portal-gnome, and a few bits in other places. There is also xdg-desktop-portal-gtk, which will be used when Magpie hits v1, and cuts ties from the GNOME infra. Around this time, Budgie should provide its own portal backend, that integrates more with the Budgie environment. This discussion will be to, well, discuss that.
Implementation
I'd like to write this in Rust, as it's what I'm most familiar with, and it in general feels nice. However, we'd need to do quite a bit manually unless/until bilelmoussaoui/ashpd#108 lands, but that's probably not a big deal. The interfaces are fairly simple.
We need to discuss how Budgie will centralize the storing of preferences, and how the portal should read them. Until then, it can be a bit of a pain to implement some bits. We'd also need to dig around in some other internals to e.g. inhibit the session from shutting down, or provide an AppChooser dialog.
Portals
This portal should, ideally, implement most of this list: https://flatpak.github.io/xdg-desktop-portal/#idm6564. I'll explicitly list some of them, and some concerns, here.
Access, Account, AppChooser
The Access dialog should already have an equivalent implemented in Budgie; the other two might not. Shouldn't be too hard to hook up.
Background
GNOME blanket allows this, and Budgie can too; the run-in-background bit is exposed in Settings (at least on GNOME 45), but there isn't any autostart menu outside of Tweaks as of the time of writing.
Email
Should probably redirect to the default app for it. Needs investigation as to how the specs interact and it's implemented.
FileChooser
This is a bit... complicated. Budgie wants to be generic and allow distros to tweak Budgie to their liking, and this includes the default file chooser; this does not play well with the FileChooser portal. We should investigate a spec for file managers that allows them to be used in any portal implementation, and provide a list of file managers that support this spec. This would allow Budgie to stay generic and malleable and not need to maintain its own file manager.
GlobalShortcuts
Needs a UI somewhere in Settings, and a dialog to expose it to the user. It can also be blanket allowed, but that needs more discussion.
Inhibit
Needs to see how this works right now, if at all, and hook it up as appropriate to the implementation.
Print
Needs investigation of how the internals work, and how to expose it to the user.
ScreenCast, Screenshot, RemoteDesktop, InputCapture
Magpie v1 should provide an API to list all the windows and displays, and to get a PipeWire file descriptor for their appropriate buffers. Then the portal just needs to request that file descriptor and send it over the portal. The wlroots portal will not be sufficient here, as it only does fullscreen sharing.
The ScreenCast logic will be used in the Screenshot portal too, in order to capture: the screen, a specific area, and a specific window.
RemoteDesktop will rely on ScreenCast and InputCapture.
InputCapture needs to either have libei implemented in Magpie v1, or a Wayland protocol for libei to build on top of. See https://gitlab.freedesktop.org/libinput/libei/-/issues/1 for more information.
Settings
We need to discuss how Budgie will be setting and reading any settings, either internally in Budgie or for this portal. Otherwise, it's just implementing the
org.freedesktop.appearance color-scheme
andorg.freedesktop.appearance accent-color
preferences.org.freedesktop.appearance button-placement
may also be a Setting in the future.Beta Was this translation helpful? Give feedback.
All reactions