On Mon, 2023-05-29 at 17:56 +0200, Ladislav Slezák wrote:
Dne 29. 05. 23 v 12:12 Ancor Gonzalez Sosa napsal(a):
Where is the rest of Canary gang? oSC feels incomplete without them!
Yay! :-)
:)
Based on those same conversations, I would also expect openSUSE use Agama as a multi-product installer.
As LCP pointed to me, that implies we need to resurrect at some point the theming and branding topic.
Good point! I think as the first step we should split the CSS into two parts, basic theme independent styling (layout, spacing, ...) and a custom part (colors, images, fonts, ...). And package the custom part to cockpit-agama- branding-default package (or something like that).
Personally, I have no a clear idea how to do it yet. It's something I have thought about a few times already, but as you know... we have been busy. I wouldn't split the CSS for theme reasons. I'd use CSS Custom Properties instead. If we provide a public and stable "CSS Variables API", the consumer should be able to influence everything exposed, no matter if is an space or a color. Also, we have to bear in mind high contrast theming and friends, not only the custom one. One idea that comes to my mind if to add a "global" class name in the body and load a custom file (initially empty? initially missing?). That file could be installed by a package, as Ladislav proposed. But that file should contain only one CSS class (theme-custom?) redefining the variables it wants to change. These are just rough ideas. My apologies for not explaining it more clearly, I'm in a hurry. About the name, I'd avoid calling it "cockpit-". I know cockpit plays a important role in the Agama world, but I'd go for agama-custom-theme or so. About CSS variables, beyond the proper name for each one, I'd like to prefix all of them with "--agm" or similar. As a last thought, I would like to avoid having the same problem we had when trying to change the look & feel of the cockpit. To learn more, please visit https://github.com/cockpit-project/cockpit/pull/17437 and follow the links to learn more. That is my two cents.
I guess the very important part will be the documentation: what can be branded and how, how to build and package the custom branding. That should be easier with our own default branding package, it could serve as a template.
A bit related topic: As Agama gets more official we should be prepared for a request to display a product license before installation. I'm pretty sure at some point we will be asked for this. And we should be prepared for that, like how to solve that in automatic installation, etc... > I also had some conversations with Uyuni/SUSE Manager developers. They like the part
about being able to track the installation process, but they are not so sure our current solution based on D-Bus would suffice to them. Some extra work is still needed to close the gap (hopefully without blowing up the memory consumption).
The question is which API would they prefer. There are several possibilities:
- Command line interface - we already have it, should be easy to extend - machine output (JSON?) is easy to support - but needs SSH access and you need to know the login credentials (currently they are fixed, but that's not nice from security POV...)
- REST API - unfortunately Cockpit does not allow to add a simple REST API for querying the current progress, Cockpit is more or less just a static webserver (providing static HTML + JS + other files) - ugly hack: re-write the progress at /usr/share/cockpit/agama/progress.json file whenever it changes, then it would be available as https://<server>:9090/cockpit/@localhost/agama/progress.json, a bit less ugly would be writing to ~/.local/share/cockpit/agama-progress (or whatever different name) with some special manifest.json - the correct solution would be to implement a simple dedicated web server running on a different port and watching the D-Bus service
- Webhooks - the backend service would send a POST request with the progress data payload (JSON) to the configured URL whenever the status changes - the question is how to pass the URL (boot parameter?, via command line?,...) - this should be more efficient, instead of regular polling you would have callbacks, also sending a simple HTTP request does not need many resources (compared to a dedicated webserver)
Ideas? Comments?