Hi Fedora i3 SIG, I work on a desktop environment project called Regolith[1] which currently supports Ubuntu-based systems. We have an open issue[2] for porting our desktop environment to Fedora and a user noted the existence of this project and suggested maybe we could work together. I clicked around a bit in your project pages but did not find much in the way of concrete details. Things that I am interested in, and may be topics for discussion:

1. How do you intend to handle the "desktop environment" stuff (Set screen resolution, sound output, user locale, etc.)?

2. How do you intend to create your package dependency graph?

From the 2 or so years I've worked on this project, I think a big design challenge is how to allow for users to modify and extend their desktop in such a way that updates over time do not break user configurations but still allow the freedom to make changes under the hood. I am working on a design for decomposition of an i3 config file into conf.d style partials[3]. I'd also be curious as to what insights you may have here.

Currently I am working on breaking the package topology of Regolith to allow for easier porting to package formats such as RPM and host operating systems such as Debian, and potentially also entirely different desktop systems such as Wayland/Sway.

Or are you planning to provide this via an external daemon/tool instead

That sounds great, please keep us updated!

Hi Ken, > I work on a desktop environment project called Regolith[1] which > > currently supports Ubuntu-based systems. We have an open issue[2] for > > porting our desktop environment to Fedora and a user noted the > existence of > > this project and suggested maybe we could work together. I clicked > around > > a bit in your project pages but did not find much in the way of concrete > > details. Things that I am interested in, and may be topics for > > discussion: > We took Regolith Linux as well as Manjaro i3 community edition as part of our inspiration, thanks for that great project. > > 1. How do you intend to handle the "desktop environment" stuff (Set > screen > > resolution, sound output, user locale, etc.)? > > 2. How do you intend to create your package dependency graph? > > > > From the 2 or so years I've worked on this project, I think a big > design > > challenge is how to allow for users to modify and extend their desktop > in > > such a way that updates over time do not break user configurations but > > still allow the freedom to make changes under the hood. I am working > on a > > design for decomposition of an i3 config file into conf.d style > > partials[3]. I'd also be curious as to what insights you may have > > here. > > > > Currently I am working on breaking the package topology of Regolith to > > allow for easier porting to package formats such as RPM and host > operating > > systems such as Debian, and potentially also entirely different desktop > > systems such as Wayland/Sway. > Dan answered most of your questions, if you have anything else to share and/or to ask, feel free to reach us here. Best regards, -- Eduard Lucena Móvil: +56962318010 GNU/Linux User #589060 Ubuntu User #8749 Fedora Marketing Representative

If I understand correctly, you should run the script that serves the

Hello Ken, Thanks for the link to the package list. Seems reasonable, I looked > around for the i3 config file you indend to ship but coudn't find it. The > RPM/Fedora packaging files are unfamiliar to me. (I am sort of self-taught > on how to roll Debian packages but am by no means an expert.) Do you > intend to ship an i3 config file other than what's provided by the upstream > project? If not, then I am guessing it's expected that the new user > experience involves directly editing the i3 config file? > In Fedora we use an "Upstream first" approach [1]. So yes, we ship the default i3 config file. > The i3 config file partial implementation is just a shell script that > combines files from specific directories into a single file and passes it > to i3 upon launch. There are no changes required to i3. Doing this opens > the door for a number of use cases but the primary one we need this for now > is to decouple the i3 config file from the package specification. For > example, you use `feh` to provide the background. If `feh` is referenced > in your i3 config file then you would not permit users to uninstall the > program as it would break thier system. With a modular, "conf.d" style i3 > layout, a meta package that depends on both feh and it's associated i3 > config partial could be cleanly added removed as needed by users. > This sounds interesting. If I understand correctly, you should run the script that serves the config file to i3 each time a modification is done, like restarting httpd every time you modify a config file, am I right? I hope to hear more from you. Thanks for contacting us. Best regards, -- Eduard Lucena Móvil: +56962318010 GNU/Linux User #589060 Ubuntu User #8749 Fedora Marketing Representative