Lucien_Lachance ubuntu budgie hasn't said anything, they will probably use Solus Budgie with EFL, or fork it... but they don't even have official forum, just ubuntu one.
Let's hope they don't end with GTK, forking budgie-gtk will not be a good long term decision. Also endeavourOS users brought more consequences from GTK+... that is cinnamon and mate devs choice.

      algent whoops, guess I didn't saw that... btw they don't know yet how things are going to be:

      All good questions. I’m as much in the dark as you.

      Or does it mean Ubuntu Budgie might stay with non EFL Budgie ?

      That depends on the community … kind of difficult to say without actually seeing what progress has been made. As to when - who knows? No time-lines makes planning impossible.

      In the mean time - lets concentrate on the here and now - what we all can do to make & do stuff better for all concerned with the tools & resources available.

      Source: fossfreedom @ Ubuntu Budgie Team Member

      Let's hope they don't fork it... as it would lead to more fragmentation. And their users will have no freedom, going back to the old gnome or everything fight.

          YuriTheHenrique I've had a discussion with an Ubuntu Budgie team member that made it pretty clear that they are excited to see how an EFL-based Budgie progresses, how they (or at least this specific member) can get involved (both for Budgie as well as helping the EFL ecosystem), etc. It was at least this team member's belief that the blog post detailed what many have been thinking about GNOME and GTK for a while, and while it of course does not necessarily reflect the entire viewpoint of the Ubuntu Budgie team, there is at least some in their neck of the woods that are at least understanding of this choice in direction.

          This individual originally inquired about having a 1-to-1 meeting, however I instead proposed that there be a broader meeting between Solus and Ubuntu Budgie folks, as this would provide an opportunity to ensure that everyone's needs are known, assessed, and if possible worked on during the development process, to best ensure that they are able to best utilize Budgie going into the future. That team member said they would relay it to the Ubuntu Budgie team and get back to me on it. Not sure where that'll go (if anywhere) but I am being mindful of downstreams like them and would like to have constructive discussions with them on it, rather than this whole "let's just wait and see" viewpoint. Hell, if it could even be recorded and uploaded for posterity sake and increased transparency that'd be pretty dope too.

          A fork of Budgie is not really necessary. While there will be more components related to Budgie Desktop to facilitate the more modular approach and ensure we have software like our own control center to best expose Budgie functionality in addition to other system integration, really only the graphical aspects of Budgie will "need" EFL (at least so far, that's the intent). While yes, Budgie panel, Raven, etc. plus a Control Center would be significant graphical applications to be using EFL, we are not in the business of making it harder for downstreams to pick whatever defaults they want for other applications (that would be silly and pointless) and would like to do what we can to make theming as painless as possible.

          Of course, it is their right under both copyleft and permissive licensing to fork Budgie, however that would necessitate them rebranding and that level of divergence wouldn't really help them any.

              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.