JoshStrobl the last time I saw OrbTK it only had a screenshot of the calculator example and it didn't look very interesting. seems it's more fleshed-out than I expected- I may try porting one of my programs to this!

    I know it is pretty early on but am curious how the transition will take place. Do you plan on having a separate repo or desktop package for building and testing? Will there be an opportunity for opencollective contributors to help by testing? I absolutely love the dedication you all have and cannot wait to be a part of this transition.

      njakes The way I wanna go about it is having a "beta" branch + set of packages people can test out when it's ready, and I do intend on having testing images for folks (plus we'll need them internally, so win-win).

      I want to take the same path with the Software Center too, where you can install the new Software Center as a "beta" to start testing whatever is there (for example, it might start before sol is even done so we can test the other plugins), but still have the old one around for normal eopkg operations. Then once bugs are worked out and sol is integrated, all we gotta do to roll it out completely is update the main solus-sc repo package.

        Question, trying to understand the process of changing a ToolKit middle of the game. šŸ˜„

        Are you able to C/P into the EFL or is this a complete new build ?
        So like a 100 hours or 1000's of hours of work?, reading EFL the API components list looks very involved. šŸ¤Æ

          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.