Quite a big release I would say. They said they fixed drag and drop between Wayland and Xwayland windows which is absolute fire if they did.
After the last experience, very proudly homophobic.
Quite a big release I would say. They said they fixed drag and drop between Wayland and Xwayland windows which is absolute fire if they did.
It can be a theme or a plugin issue.
I hope at least distros will make the switching automated because without it a lot of users will have issues, especially since Ubuntu and Fedora use GNOME by default.
Huh but GPUs only support it since like 2016 or 2017. Older ones won’t be able to render GTK4?
It’s called the MacBook Air series and it has 2 types: x86 (with Intel CPUs) and ARM (with Apple M series CPUs). If it’s the first type, you can expect stuff to work on almost any of them (except for WiFi which needs installing drivers manually after Linux installation). If it’s the second one then you’re out of luck because the support for them is very basic.
But why do you need a server for such a program? Can’t it be P2P or with the server stuff running on the client machine?
I guess it’s just written in Rust.
Fyi messing around with drivers can even cause permanent hardware damage.
I’m not that much of an expert but I know display protocols, init system and audio protocol (there are 2 but the new standard supports stuff made for the older one) are standardized.
Afaik Signal servers have nothing to do with it. There are 3 possible situations depending on what app you choose.
Official Signal app. It asks Google to check Signal servers for notifications and to send them to you if there are any.
Molly FOSS. It connects directly to Signal servers without any push middleman.
Molly UP. It asks the push notifications provider you choose (but not Google) to check Signal servers for notifications and to send them to you if there are any.
Ultimately, it’s the apps and not the servers who decide if they want to use Google’s services or not.
Such stuff is almost perfectly standardized on Linux (and the risks are there too).
lack of some kind of standardization
Standardization = monopoly risks. It’s not worth it in the first place.
when everyone works on something different, the quality spreads out to where it’s mostly just mediocre stuff across the board.
I wouldn’t say that’s the only problem. We have pretty high quality stuff on Linux. The other problem is that choice always means differences between options which makes perfect integration hard or even impossible.
Molly FOSS and Molly with UP replace the Google’s notification system with websocket and UnifiedPush respectively for its own notifications. Google (hopefully) doesn’t have access to all notifications you get on your phone but only to those sent to apps that utilize their push implementation which Molly doesn’t use.
Well Google can still lock Mozilla out of the features and cooperation if they do something Google doesn’t like. It’s just one example. Nobody should ever trust Google.
Idk about Element but Signal uses the Google’s insecure implementation if the device has gapps installed and it uses the traditional system which is not push if gapps are not installed.
I know about that but afaik almost nobody uses it. The only app I know that supports it is Mercurygram which is a Telegram client.
There already was a post like this this year but now my answer is “a standardized push notification system (most likely federated) that’s actually possible to be implemented in a user friendly way”. Google doesn’t want to encrypt theirs afaik and apparently some people are concerned about the traditional “every app is responsible for its own notifications” approach consuming much more battery, even though I didn’t notice it myself (I guess it’s possible if you have 50+ apps installed but it’s not something that should be a thing in the first place).
Google’s involvement should always raise concerns but I guess it’s good Mozilla is trying to improve stuff.
Well it can also make everything worse. Some languages are good for DE development and some aren’t.