So Solus going in one direction, PopOS going in the other direction. Xfce, your turn?
This is exciting. It seems as through the desktop they’re building is not GTK-based or at least I would assume so.
edit: It seems like it’ll be gtk-based for now.
Both Solus and PopOS are distributions, that just happen to develop their own desktop environment too. Xfce is not a distribution, but a desktop environment.
Regarding thir development, they just completed the transition to gtk3. Next step will probably be gtk4, but that won’t happen for 2-4 years (guestimate).
Similar to XFCE, the Raspberry Pi OS desktop managed to bring up their LXDE-based desktop to GTK3 as well (with the recent Raspberry Pi OS’ 32-bit bullseye release). My impression towards GTK4 is that it’s still really new-fangled, as far as actual adoption in software (beyond the gnome desktop’s use of GTK4). And there seems to be some serious dissatisfaction around the migration from GTK3 to GTK4, as it’s a rather complicated refactoring in many cases.
I’m curious to see what Pop_OS! manages to come up with…
I am currently running Pop!_OS on my main machine. I am already considering a move to Fedora, Fedora has worked out really well so far on my laptop but I’ll only move if the new Pop is not suitable. I am sure it will be quality but will I like it. Only time will tell. A lot of people put a lot of effort into these distros so its unfair to criticise them too much, either they are suitable or not.
There are other options with LXDE,
LX-Qt has just released version 1.
So it is stable if you do not mind stepping into the Qt / KDE environment.
Lots of interesting changes going on, to be sure. I do think we have to be careful about what conclusions we draw from all of this until after the dust settles. I have read quite a bit and I already have my biases but I am trying not to allow them to cloud my judgement. A peaceful separation is probably best if members of a project cannot work together adequately.
That said, I am excited to see what Pop!_OS does without the restrictions of Gnome and what Gnome can do when it can just to what Gnome does without distributions having to change bits to make it more broadly functional. Let the chips fall where they may.
Also be interesting to see if Solus breaths some more life into Enlightenment or gives up and joins PopOS in their adventures with Rust.
Not the first time we had friction in Open Source. Didn’t Gnome decide to go it alone after an initial change in Qt licensing?
But that was before my time, so …
There is constantly some kind of friction in the Linux and open source community. That’s what happens when you put people in the mix.
Quote here from KDE developer Nate Graham,
“with projects like GNOME and ElementaryOS competing to be the Apple of FOSS". You could easily take that as putting them in the firing line but it’s more positive than that as Graham continues “I think there will absolutely be room for projects like theirs; in fact I think it’s highly likely that they’ll offer a better user experience than we do for people who fit within the usage paradigms they focus on–just like Apple does”.
It’s part of why I ended up moving from GNOME to KDE myself, that flexibility of setting it all up how I want it to be, not how designers think it should be. I cannot see myself moving away from Plasma as my own desktop environment on Linux any time soon. Looks good, works well and doesn’t get in the way of gaming.”
As posted on GamingonLinux
Without friction, cars don’t move.
Do you detect a pattern here?
Quote from Budgie
“1. REQUIRED: Deprecate our use of gnome-bluetooth in favor of a combined use of bluez and upower directly. We would need to move Budgie 10.x over to the new GNOME Bluetooth API at some point anyways, so best to kill two GNOMEs with one stone and move directly to bluez. At the same time, we want to make sure the Bluetooth applet / Battery applets and Raven itself expose functionality to allow for quick connect and disconnect with Bluetooth devices like headphones, monitor power levels (maybe they are over 9000?) for Bluetooth devices, and more.”
Quote from Linux Mint newsletter,
“Blueman replaces Blueberry
A long time ago Linux Mint shipped with GNOME Bluetooth, a utility which worked well in many desktops.
When it lost its frontend to become part of gnome-control-center, GNOME Bluetooth suddenly only worked in GNOME. We need a solution for Cinnamon, MATE and Xfce. It didn’t make sense for each desktop to develop its own bluetooth tool and we didn’t want to write an entire Bluetooth app from scratch so we wrote an XApp to bring back the missing frontend that had been removed.
This XApp was called Blueberry and it was just that, a missing frontend for GNOME Bluetooth. This allowed us to continue to use GNOME Bluetooth in many desktops for the last 7 years.”
“Starting with version 42 GNOME Bluetooth is no longer compatible with Blueberry. Blueberry would need to undergo significant changes to work with it. There is also frustration upstream from the GNOME Bluetooth development team who simply does not want to have users from other desktops than GNOME and so Blueberry will probably get discontinued.
Blueman on the other hand welcomes users from all desktop environments. It does not rely on GNOME Bluetooth. It’s a GTK frontend for the Bluez bluetooth stack.”
Bit more on PopOS’s COSMIC desktop, development on Rust based Iced.
Budgie 10.7 release.
Cosmic development continues…
Quoting from blog.
“For those of you who don’t know, System76 is moving the feel and front-end functionality of Pop!_OS to a faster codebase, giving you a familiar, but snappier, experience. And I’m here to update you all on the new features and designs the System76 team is building along the way. Once we have a date for you to try out this new desktop environment in a public alpha, I’ll give you that too :)”
Watching this DE progress has seriously had me question how much I’m investing on Python resources and wondering if I should shift my focus to Rust. I am liking what I see in the sample art.
I don’t think you will be harmed by continuing to learn Python. Rust and Python are for quite different purposes. Rust is a lower-level language along the lines of C/C++, Objective C, and C#, while Python is a higher-level language like Ruby, Perl, etc. Also, programming languages are like spoken/written languages in that the more of them you learn the easier it is to pick up new ones.