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? > > > >
