craigtoyoracer Are you able to C/P into the EFL or is this a complete new build ?

Nothing was going to be copy / paste from Budgie 10 to 11 regardless of the toolkit. It isn't just a matter of changing toolkits, Budgie 11 has always been a complete rearchitecture of Budgie and remodel of how many components of it work.

    Here's to hoping things will move smoothly after this change, it'll definitely take quite the effort for the move but I trust you guys with keeping Solus such a nice release. I just pray it doesn't end up having an E17 feel to it, because I really dislike that DM hahaha.

    Does anyone have any idea on how these GNOME developments affect other GTK DMs like Mate and Cinnamon?
    Nevermind, apparently things are gonna be fine for those DMs as well since they ship their own aps. I'm still reading about it all and it's... kind of a mess. Some of those GNOME devs really sound hard to work with to say the least.

    JoshStrobl

    When the time comes, and you're looking for Budgie 11 testers, please keep me in mind. I have a pretty robust desktop that's not doing much at all. (Currently just serving .ISO files via torrents, and that is eminently uninterruptible.)

        WetGeek When the time comes, and you're looking for Budgie 11 testers, please keep me in mind. I have a pretty robust desktop that's not doing much at all.

        I have some spare VMs too... šŸ¦Š

            Solarmass I have some spare VMs too...

            As do I, and that's what I had in mind, actually. Being able devote several testing VMs instead of just one host workstation is very appealing. As is the easy availability of snapshots that can easily be discarded in the event that a bug causes the VM to become unresponsive.

            Eventually, of course, DEs have to be tested on hardware, but much testing can be accomplished before it ever comes to that. Not to mention, tests can easily be done on distros other than Solus, where Budgie might be offered as well.

              From what I see, it seems a good time to unhitch the wagon from the GNOME folks. EFL is potentially a blazingly fast environment (as shown with Enlightenment), so that seems a good base to build with.

              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.
                                      šŸ˜„