JoshStrobl I am not a Solus user or a Budgie user for that matter, but I have been working with Gtk+ for a while and have been coming to the much the same conclusion as you outlined in your blog post regarding the need for an alternative ecosystem. I have seen many of the issues that you outlined and a few others, have seen gtk+ devs close but reports when multiple people confirmed that the bus were still unfixed, and am very concerned about the viability of using the toolkit in any context outside of gnome.

C and Rust are both in my comfort zone. I would be interested in helping with the effort not just because it's interesting but because I think it would be beneficial to the wider community. I'm going to go ahead and start looking at the EFL libraries and see how my existing skill set translates.

Are there currently any bindings for Rust (even if incomplete), or is this aspect a green field? I'd be interested in helping there as well as application development. Tentatively of course.

      nfisher1226 As noted in my blog post, the only EFL bindings (at least that I have found) are https://github.com/araujol/rust-efl and they're really old (7 years out of date). They might provide a good basis to work off of, but I haven't had the time to sit down and take a thorough look yet, or determined if I want to bother with the legacy API or immediately start with the EFL unified API, despite the fact it lacks many features from "legacy" at the moment.

      Obviously if you want to pursue EFL binding development, go ham. I'm sure we aren't the only ones that would make use of them, and it'd be a good way to contribute to the ecosystem 🙂

      I will mention that you shouldn't hesitate to ask where you can help get involved with EFL in the #e channel on libera IRC. Everyone I have engaged there has been helpful and excited about newcomers.

          JoshStrobl I have spent the last years loving the Budgie desktop for its customisability while having the same concerns you expressed regarding GNOME's direction and general attitude.

          And although this comes with the usual concerns (how will it work with theming, how to build an ecosystem, will widespread GNOME application look completely alien, will it be possible to achieve feature parity, etc.) I am at the very least curious

          So I'd like to help too. I don't consider myself an experienced dev (and as a matter of fact have no experience in app design) but I do know how to write some C and Rust code (even though most of my experience comes from an embedded and robotics point of view).

          Hopefully, I can find the time next to my Masters thesis. In any case, godspeed.

          Also, I can write Java, ARM Assembly, Matlab and Oz code but I doubt it'll be useful...

            JoshStrobl yeah, last commit on rust-efl was in 2014, so in terms of Rust that's ancient. I'll still look at it, but it might be more productive to start from scratch.

              the "terminology" terminal in enlightenment is a real nice terminal. You should consider using it.
              Just my 0,02$ Using EFL is going to be a big challenge but I'm sure Solus team is up to the task.
              😄

              [unknown] EFL is indeed an interesting choice. Can't say anything more about it, since I actually never used it.

              I'm surprised that no one has mentioned EliveOS.
              It is THE Enlightenment distro ... though the developer is still using 16 instead of 24.
              https://www.elivecd.org/

                George depends on your opinion of Go. I'm a little torn- it's easy to use but error handling is clunky, and from what I've heard the package management is bad and its masking of complexity can cause problems. Fyne does look cool though, and Go worked well for the one thing I built in it!

                edit: a garbage-collected language like Go might cause problems for a desktop environment if it freezes briefly every time it frees memory. not really sure on that one though.

                    synth-ruiner So, as a long time Go developer, I think most of the flack it gets is either a misunderstanding or no longer valid.

                    Error handling in Go is explicit because the alternative is Exceptions which tend to encourage passing an error on to upper layers in a non-obvious way, when often the problem can be handled immediately and better in the context of where it was first encountered. Coming from years of Java and C++ development, Exceptions are much harder to reason about and can be maddening to track down the source without good tooling.

                    Package management in Go was largely solved with the introduction of Go Modules. Before that, the biggest problem was many competing solutions that were cumbersome and problematic when crossing from one project to another. Most Go projects have standardized on modules now which has been a godsend for the rest of us. The only real complexity left there is multiple-versioning of modules with the same major version and that's just a matter of time.

                    Garbage collection hasn't been a problem in Go for a really long time. Most garbage collection happens asynchronously and the stop-the-world pauses are sub-millisecond in most cases now. Nowhere near disruptive enough to cause problems. Let's also realize that C++ used to be garbage collected and that Java still is, both having no problems at all handling GUI without freezing things.

                    George As far as Fyne itself is concerned I think it's a decent start at a Go toolkit, but I'm not really fond of its insistence on following Material Design principles. That tends to lead to UI which have too much space where they don't need it and not enough space where they do. I also think there's a tendency to not have enough contrast between colors which is bad for accessibility.

                          DataDrake thanks for the comprehensive reply! I agree that exceptions are terrible and that explicitly checking for errors is the right way to do things, it's just that I'm a bit spoilt by Rust and its nice Option and Result types, match expressions and stuff like that. maybe there are similarly nice expressions in Go but I'm a newbie and don't know much 😅

                          like I said, I wasn't actually sure if garbage collection would be a problem, so I'm glad to hear it's totally negligible.

                          +1 for the accessibility issues of material design, too - most of the visual elements we traditionally use to hint at interactivity get stripped away, like bevelled buttons, scrollbars and such.

                            Just to extend the list of available toolkits: I stumbled across ImGui in a tweet of John Carmack. There seems to be a sufficient number of maintainers and some "big" sponsors. Unfortunately, this is a toolkit for C++ and as Josh mentioned in his post, C++ is not an option. But maybe it could be interesting for people here who needs a lighter GUI toolkit for C++ than Qt.

                              saitam I've previously assessed IMGUI and while it's useful for throwing things together for professional use, I don't think it's really a good option for user-facing GUIs. Between its dated look and feel and limited feature set, it isn't quite where we need it to be. If it were just me using a computer as normal, it wouldn't be an issue. But we have to account for user tastes and accessibility.

                                Very well written!
                                It’s always just the drama with gnome stuff.
                                They have a very strict idea on how I should use my desktop, I think I’d rather not.
                                Super excited for budgie11!

                                6 days later

                                LarryDC I use EliveOS with E24 and it still have some ruff edges. Both version 16 & 24 are available but the core of elive users are mostly E16. E24 has a lot nicer configuration tool and personally I prefer E24. But I would say that if you want to use wayland it is not very stable yet. I hope it gets better soon because wayland is going to be necessary for the future. There seems to be possibility that EFL could use Wayfire under wayland (wayfire is Compiz rewritten for Wayland).
                                Regards,
                                Bernard

                                  Hello All.
                                  After reading the original post, I decided to write here because the situation worries me.
                                  The fact is that the Solus distribution is also used by blind users. Although there are currently accessibility issues, Solus is the best of today's distributions for the blind. But if users used to install only Solus-MATE, recently, people are starting to be interested in Budgie, as accessibility in this work environment has improved.
                                  So I want to ask: Please keep accessible.
                                  Personally, I use MATE because this environment is currently the most accessible for blind users, but I know for sure that other users are interested in Budgie (particularly, from time to time, Budgie is discussed in the Orca mailing list).
                                  I would also like to take this opportunity to thank Solus. This is a great distribution that is the best in everything. So I would like Solus to be the best in terms of accessibility.
                                  Sorry for my bad English.

                                  I know Solus main focus is dark theme but will there be an option for white one also?
                                  I'm playing with CuteFish and it looks amazing.

                                  Possibility of changing terminal transparency by your taste is really nice 🙂