Bottles: GUI front end to run Windows software on Linux(usebottles.com)
usebottles.com
Bottles: GUI front end to run Windows software on Linux
https://usebottles.com/
238 comments
>Say what you will about GTK and Gnome... for beginners on an operating system such as Ubuntu, having a consistent application concept is very important.
Consistency is important but is not like the majority of the apps are GTK3 (or whatever is latest) with the GNOME styles even if those GNOME designers pretend nothing else exists and nobody should remove the GNOME branding from the GNOME apps.
Just want to mention that GNOME are the bad guys, KDE distributions will provide GNOME integration with packages and themes that attempt to keep Qt and GTK application consistent in look and feel but I never seen GNOME distros attempt to integrate with the non-GNOME apps.
Consistency is important but is not like the majority of the apps are GTK3 (or whatever is latest) with the GNOME styles even if those GNOME designers pretend nothing else exists and nobody should remove the GNOME branding from the GNOME apps.
Just want to mention that GNOME are the bad guys, KDE distributions will provide GNOME integration with packages and themes that attempt to keep Qt and GTK application consistent in look and feel but I never seen GNOME distros attempt to integrate with the non-GNOME apps.
> GNOME are the bad guys
Just because you disagree with them, it doesn't make them the "bad guys".
Just because you disagree with them, it doesn't make them the "bad guys".
They're making their desktop environment and apps into a walled garden on a platform like Linux. Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
They also engage in carefully crafted doublespeak when it comes to things like extensions and user choice regarding configuration.
Call it what you want but they certainly don't intend to play nice with anyone and have adopted the approach of "my way or the highway". Perhaps they're emboldened by all the corporate backing they have from Red Hat and SUSE. They also have the advantage of being the default DE on most distros. Hell, even distros like NixOS encourage users to use GNOME, which is absolutely insane when you think about it.
They also engage in carefully crafted doublespeak when it comes to things like extensions and user choice regarding configuration.
Call it what you want but they certainly don't intend to play nice with anyone and have adopted the approach of "my way or the highway". Perhaps they're emboldened by all the corporate backing they have from Red Hat and SUSE. They also have the advantage of being the default DE on most distros. Hell, even distros like NixOS encourage users to use GNOME, which is absolutely insane when you think about it.
> Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
There have always been apps more heavily integrated with GNOME vs GTK apps. Gtk4 is easier to port to other platforms, if anything it should be less painful than it has been before.
There have always been apps more heavily integrated with GNOME vs GTK apps. Gtk4 is easier to port to other platforms, if anything it should be less painful than it has been before.
> Gtk4 is easier to port to other platforms, if anything it should be less painful than it has been before.
Oh, how desperately I wish this were true. My evidence is purely anecdotal, but I've found GTK4 to be almost completely unusable in my time working with it, so much so that I've basically decided to skip this release altogether and just stick with GTK3 for all intents and purposes. It started when I wanted to pull my Glade projects in to the new framework so I can build my apps with XML instead of writing it by hand... oops, that method has been unsupported. But don't worry! There's a replacement app right around the corner that's... not finished yet. Okay, I guess that's not a big deal, I'll just re-write everything by hand! Now it's compiling and doesn't look the least bit native on my system. And there are compositor issues. And the text looks ass-ugly too.
Asking around on IRC, I was told everything from "use Flatpak" to "stop trolling" to "your workflow is unhealthy/insane/unsupported". It would appear that GTK4 is only intended for GNOME extremists, unfortunately. If there are any portability improvements I won't likely see them.
Oh, how desperately I wish this were true. My evidence is purely anecdotal, but I've found GTK4 to be almost completely unusable in my time working with it, so much so that I've basically decided to skip this release altogether and just stick with GTK3 for all intents and purposes. It started when I wanted to pull my Glade projects in to the new framework so I can build my apps with XML instead of writing it by hand... oops, that method has been unsupported. But don't worry! There's a replacement app right around the corner that's... not finished yet. Okay, I guess that's not a big deal, I'll just re-write everything by hand! Now it's compiling and doesn't look the least bit native on my system. And there are compositor issues. And the text looks ass-ugly too.
Asking around on IRC, I was told everything from "use Flatpak" to "stop trolling" to "your workflow is unhealthy/insane/unsupported". It would appear that GTK4 is only intended for GNOME extremists, unfortunately. If there are any portability improvements I won't likely see them.
If you depend on having a GUI builder then I agree it makes sense to wait for that to be stable before switching to GTK4. It's being worked on but progress is slow because of a severe lack of contributors. I don't know anything about compositor issues but it's aimed to give the text a substantial fix in GTK 4.6.
>I was told everything from "use Flatpak" to "stop trolling" to "your workflow is unhealthy/insane/unsupported". It would appear that GTK4 is only intended for GNOME extremists,
I don't see how that has anything to do with "extremists". The GNOME IRC is probably a bad place to ask for help with distro packaging, the focus is on Flatpak because that's realistically the only distro-agnostic packaging that upstream can support. For help with packaging apps for your distro you'd have better luck asking on your distro's IRC.
>I was told everything from "use Flatpak" to "stop trolling" to "your workflow is unhealthy/insane/unsupported". It would appear that GTK4 is only intended for GNOME extremists,
I don't see how that has anything to do with "extremists". The GNOME IRC is probably a bad place to ask for help with distro packaging, the focus is on Flatpak because that's realistically the only distro-agnostic packaging that upstream can support. For help with packaging apps for your distro you'd have better luck asking on your distro's IRC.
> If you depend on having a GUI builder then I agree it makes sense to wait for that to be stable before switching to GTK4.
Correction: traditional XML stylesheets were removed with the release of GTK4 so they could introduce a new paradigm, one that was not ready to replace it. I really don't know what to tell you here, because it's such a vast departure that it's going to make the porting process to GTK4 nearly impossible for most people. It's such a braindead, no-holds-barred move that it simply feels disgusting to me. Here we had this perfectly functional feature, and the GNOME devs, being the impractical idealists they are, said "let's get rid of it, offer a replacement and not develop the replacement". Same thing happened with LibAdwaita, GNOME 40 and pretty much everything else they seek to """improve""".
> It's being worked on but progress is slow because of a severe lack of contributors.
Who's fault is that? Is it the aggressive, unfriendly leadership? Or maybe it's the GNOME superstar celebrities, who make completely bonkers changes and expect the rest of the community to follow their lead without question? Maybe it's the lack of directive in their issue trackers, where their lead contributors decide to waffle on major issues instead of taking the directive to just shave the damn yak?
I don't care that they lack contributors. I really don't. That's a grave they've dug for themselves by ostracizing the rest of the community, and it's one they're going to have to deal with for years to come. They had opportunities to build bridges, and they tore them down. They harassed other distribution maintainers when they tried offering help of their own. They've shot themselves in the foot here, plain and simple. GTK2 and 3 weren't remotely this bad or unusable at launch, and it just makes me sad to see people clinging to elitism instead of pragmatism when building an inclusive, accessible desktop. If their ship is sinking, I'm perfectly contented to stay onboard GTK3 and watch as they sink beneath the surface. Several people said this was a bad idea, but it was their hubris that ultimately ruined GTK4. If they need "extra contributors" to fix that, then they should have thought about that before telling everyone else to screw off.
> The GNOME IRC is probably a bad place to ask for help with distro packaging
1. I was in freenode.
2. I wasn't asking about packaging.
My concern was getting my app to look right on every desktop that it ran on, which it most clearly did not. The text was distorted and completely unacceptable for distribution, there were black bars drawn around the window on half the desktops I tried it on, and the look-and-feel was inconsistent across systems. Utterly unbelievable for a toolkit that was trying to pride itself on accessibility.
> the focus is on Flatpak because that's realistically the only distro-agnostic packaging that upstream can support
The issue is that they don't even support that. Flatpak has over 600 open issues of it's own, and implementing it can oftentimes lead to more work, nonfunctional features (like distro-native features in Bottles, for example) and infinite bikeshedding. Every argument I've seen for using Flatpak is bogus. Every one. You can cry "it needs more maintainers!" and I'll probably agree with you, but it's become such a politicized and broken mess that, once again, very few people see the value to contributing to it anymore. Mark my words (and you're welcome to call me out when I'm inevitably wrong here): Flatpak will never get "finished". It has too many esoteric features, unfixable bugs and ideological missteps to compete with package managers that existed just fine 20 years ago.
That is an issue, not a feature.
Correction: traditional XML stylesheets were removed with the release of GTK4 so they could introduce a new paradigm, one that was not ready to replace it. I really don't know what to tell you here, because it's such a vast departure that it's going to make the porting process to GTK4 nearly impossible for most people. It's such a braindead, no-holds-barred move that it simply feels disgusting to me. Here we had this perfectly functional feature, and the GNOME devs, being the impractical idealists they are, said "let's get rid of it, offer a replacement and not develop the replacement". Same thing happened with LibAdwaita, GNOME 40 and pretty much everything else they seek to """improve""".
> It's being worked on but progress is slow because of a severe lack of contributors.
Who's fault is that? Is it the aggressive, unfriendly leadership? Or maybe it's the GNOME superstar celebrities, who make completely bonkers changes and expect the rest of the community to follow their lead without question? Maybe it's the lack of directive in their issue trackers, where their lead contributors decide to waffle on major issues instead of taking the directive to just shave the damn yak?
I don't care that they lack contributors. I really don't. That's a grave they've dug for themselves by ostracizing the rest of the community, and it's one they're going to have to deal with for years to come. They had opportunities to build bridges, and they tore them down. They harassed other distribution maintainers when they tried offering help of their own. They've shot themselves in the foot here, plain and simple. GTK2 and 3 weren't remotely this bad or unusable at launch, and it just makes me sad to see people clinging to elitism instead of pragmatism when building an inclusive, accessible desktop. If their ship is sinking, I'm perfectly contented to stay onboard GTK3 and watch as they sink beneath the surface. Several people said this was a bad idea, but it was their hubris that ultimately ruined GTK4. If they need "extra contributors" to fix that, then they should have thought about that before telling everyone else to screw off.
> The GNOME IRC is probably a bad place to ask for help with distro packaging
1. I was in freenode.
2. I wasn't asking about packaging.
My concern was getting my app to look right on every desktop that it ran on, which it most clearly did not. The text was distorted and completely unacceptable for distribution, there were black bars drawn around the window on half the desktops I tried it on, and the look-and-feel was inconsistent across systems. Utterly unbelievable for a toolkit that was trying to pride itself on accessibility.
> the focus is on Flatpak because that's realistically the only distro-agnostic packaging that upstream can support
The issue is that they don't even support that. Flatpak has over 600 open issues of it's own, and implementing it can oftentimes lead to more work, nonfunctional features (like distro-native features in Bottles, for example) and infinite bikeshedding. Every argument I've seen for using Flatpak is bogus. Every one. You can cry "it needs more maintainers!" and I'll probably agree with you, but it's become such a politicized and broken mess that, once again, very few people see the value to contributing to it anymore. Mark my words (and you're welcome to call me out when I'm inevitably wrong here): Flatpak will never get "finished". It has too many esoteric features, unfixable bugs and ideological missteps to compete with package managers that existed just fine 20 years ago.
That is an issue, not a feature.
>Correction: traditional XML stylesheets were removed with the release of GTK4 so they could introduce a new paradigm, one that was not ready to replace it.
Not really, the XML format is pretty similar. In my experience it works very well, even better than the GTK3 XML, but yes it's lacking a good GUI builder.
>I really don't know what to tell you here, because it's such a vast departure that it's going to make the porting process to GTK4 nearly impossible for most people.
I can't agree, I've talked to some GNOME developers and they don't have much of a problem with it. Glade on GTK3 is not very popular among GNOME developers anyway because it causes some other issues, hopefully those will be fixed with the new GUI builder too.
>said "let's get rid of it, offer a replacement and not develop the replacement". Same thing happened with LibAdwaita, GNOME 40 and pretty much everything else they seek to """improve""".
I'm very confused to what you're saying, there are replacements for all that being developed, but it takes time to do it.
>Who's fault is that? Is it the aggressive, unfriendly leadership? Or maybe it's the GNOME superstar celebrities, who make completely bonkers changes and expect the rest of the community to follow their lead without question?
I'm also very confused what you're talking about, I've talked to the Juan (the person working on the new GUI builder) and he's a pretty nice guy working as hard as he can. I've never seen him harass or ostracize anyone or refuse questions. You're generalizing and I wish you wouldn't do that, it's rude to the people who work hard on this and offer no ill will. I've never seen any aggressive leadership or superstar celebrities there either, this is mostly self-directed volunteers working in their area of interest.
>If their ship is sinking, I'm perfectly contented to stay onboard GTK3 and watch as they sink beneath the surface. Several people said this was a bad idea, but it was their hubris that ultimately ruined GTK4.
Well you lose some other improvements in GTK4 if you do this. Those improvements are very unlikely to be brought to GTK3 because they needed an API change. That's why it's a bad idea. Of course you can continue to use GTK3 if you want but you'll continue to miss out on those improvements. It's up to you to say how long you'll be OK with that, but you should know upstream has said that GTK3 will not gain any new features anymore.
>If they need "extra contributors" to fix that, then they should have thought about that before telling everyone else to screw off.
I don't know who was told to screw off, there are open calls for contributors in all these areas.
>I was in freenode.
Well Freenode is not the GNOME IRC so I have no idea what this has to do with GNOME or GTK. Yes there are trolls and unhelpful people in random freenode channels, I never used freenode much myself for that reason. GNOME has its own IRC server, and actually I think they switched to Matrix recently.
>The issue is that they don't even support that. Flatpak has over 600 open issues of it's own, and implementing it can oftentimes lead to more work, nonfunctional features (like distro-native features in Bottles, for example) and infinite bikeshedding.
I know about some of these issues and I'm personally affected by them but what you're missing is that there is actually no other option. Getting rid of Flatpak would leave them with no real way to deploy these apps at all. It's a choice between something buggy that's being worked on (slowly) and leaving app developers out in the cold with nothing. Distro package managers don't solve the problem, they created the whole problem that Flatpak exists to solve.
Not really, the XML format is pretty similar. In my experience it works very well, even better than the GTK3 XML, but yes it's lacking a good GUI builder.
>I really don't know what to tell you here, because it's such a vast departure that it's going to make the porting process to GTK4 nearly impossible for most people.
I can't agree, I've talked to some GNOME developers and they don't have much of a problem with it. Glade on GTK3 is not very popular among GNOME developers anyway because it causes some other issues, hopefully those will be fixed with the new GUI builder too.
>said "let's get rid of it, offer a replacement and not develop the replacement". Same thing happened with LibAdwaita, GNOME 40 and pretty much everything else they seek to """improve""".
I'm very confused to what you're saying, there are replacements for all that being developed, but it takes time to do it.
>Who's fault is that? Is it the aggressive, unfriendly leadership? Or maybe it's the GNOME superstar celebrities, who make completely bonkers changes and expect the rest of the community to follow their lead without question?
I'm also very confused what you're talking about, I've talked to the Juan (the person working on the new GUI builder) and he's a pretty nice guy working as hard as he can. I've never seen him harass or ostracize anyone or refuse questions. You're generalizing and I wish you wouldn't do that, it's rude to the people who work hard on this and offer no ill will. I've never seen any aggressive leadership or superstar celebrities there either, this is mostly self-directed volunteers working in their area of interest.
>If their ship is sinking, I'm perfectly contented to stay onboard GTK3 and watch as they sink beneath the surface. Several people said this was a bad idea, but it was their hubris that ultimately ruined GTK4.
Well you lose some other improvements in GTK4 if you do this. Those improvements are very unlikely to be brought to GTK3 because they needed an API change. That's why it's a bad idea. Of course you can continue to use GTK3 if you want but you'll continue to miss out on those improvements. It's up to you to say how long you'll be OK with that, but you should know upstream has said that GTK3 will not gain any new features anymore.
>If they need "extra contributors" to fix that, then they should have thought about that before telling everyone else to screw off.
I don't know who was told to screw off, there are open calls for contributors in all these areas.
>I was in freenode.
Well Freenode is not the GNOME IRC so I have no idea what this has to do with GNOME or GTK. Yes there are trolls and unhelpful people in random freenode channels, I never used freenode much myself for that reason. GNOME has its own IRC server, and actually I think they switched to Matrix recently.
>The issue is that they don't even support that. Flatpak has over 600 open issues of it's own, and implementing it can oftentimes lead to more work, nonfunctional features (like distro-native features in Bottles, for example) and infinite bikeshedding.
I know about some of these issues and I'm personally affected by them but what you're missing is that there is actually no other option. Getting rid of Flatpak would leave them with no real way to deploy these apps at all. It's a choice between something buggy that's being worked on (slowly) and leaving app developers out in the cold with nothing. Distro package managers don't solve the problem, they created the whole problem that Flatpak exists to solve.
I'm not going to stop you from pretending like nothing is wrong if that's your prerogative. I'm letting you know here and now that there is an expanding sentiment among developers that GTK4 is a regression from GTK3, and if there are any improvements coming down the pipeline I have yet to see them. I'm not going to argue with you about this when my app is irreparably broken right now, though. Every attempt I've made to reach out to developers has either gone cold or been rejected. I fully intended to start contributing to GTK back in the v3 days, but now? The current leadership has made it clear that they don't have my best interests at mind. They'd rather scrap everything I used and promise a replacement instead of iterating on it or fixing it, which is unacceptable for a toolkit that is currently in active use. I refuse to donate my time or effort to people who disrespect me like that.
I'm a pragmatist, not an idealist. Promises mean very little, especially coming from the modern GTK team.
I'm a pragmatist, not an idealist. Promises mean very little, especially coming from the modern GTK team.
>I'm not going to stop you from pretending like nothing is wrong if that's your prerogative.
Please don't jump to this conclusion, I'm not doing that. If some GTK3 users want to continue developing GTK3 or use some other toolkit then that's absolutely fine with me. I said that before, I could even recommend some other toolkits for you to use. But I think it's a bad idea to view GTK3 as some kind of resistance against GTK4 because that's missing out on many years of improvements that would be very difficult to backport. Yes there are bugs in GTK4, but I've also talked to the developers and they are aware of them and are working on solving the issues even if progress seems slow. You can read some of the GTK4 blogs to see some of the enhancements that were made in GTK4 and decide if they're worth it to you or not: https://blog.gtk.org/2020/12/16/gtk-4-0/
>I'm letting you know here and now that there is an expanding sentiment among developers that GTK4 is a regression from GTK3
This is not really surprising or new or that much of a big deal, people complained when GTK2 was released because it changed stuff from GTK1, then they complained when GTK3 was released because it changed stuff from GTK2. It's totally understandable and normal for some to want to avoid or delay making the switch, but many others have been willing to make it for the improvements.
>Every attempt I've made to reach out to developers has either gone cold or been rejected. The current leadership has made it clear that they don't have my best interests at mind.
Well if you were on freenode then those probably weren't the upstream developers or any of the current project leadership so I think you might have a wrong impression; you're saying a whole lot of negative things but the underlying logic just doesn't really add up to me. I'm not interested to argue with you either, if you can just mention what the issue is with your app I might be able to help you.
>They'd rather scrap everything I used and promise a replacement instead of iterating on it or fixing it, which is unacceptable for a toolkit that is currently in active use.
This statement is also confusing to me, the replacement is the iteration and fixing. It's being worked on. It can't really be any other way, Glade is a very old application from the GNOME 1 days that's been continuously ported and it still inherits some old design flaws from that. To finally fix the design flaws the program needs some major breakage or a rewrite, so they decided to go with the rewrite because it's actually easier than hacking apart all the internals of Glade and breaking the whole program. And by "they" I mean the one person who has been working on Glade for the last few years and is now working on the replacement. I don't know what "promise" you're talking about either, I think it's a bad situation that only one person is working on this. He could stop working on it at any time and then you'd have no GUI builder at all, the "bus factor" on these projects is a concern right now.
>I refuse to donate my time or effort to people who disrespect me like that.
I'm not suggesting you do that, it seems more like you were asking about taking time or effort to fix your own application.
Please don't jump to this conclusion, I'm not doing that. If some GTK3 users want to continue developing GTK3 or use some other toolkit then that's absolutely fine with me. I said that before, I could even recommend some other toolkits for you to use. But I think it's a bad idea to view GTK3 as some kind of resistance against GTK4 because that's missing out on many years of improvements that would be very difficult to backport. Yes there are bugs in GTK4, but I've also talked to the developers and they are aware of them and are working on solving the issues even if progress seems slow. You can read some of the GTK4 blogs to see some of the enhancements that were made in GTK4 and decide if they're worth it to you or not: https://blog.gtk.org/2020/12/16/gtk-4-0/
>I'm letting you know here and now that there is an expanding sentiment among developers that GTK4 is a regression from GTK3
This is not really surprising or new or that much of a big deal, people complained when GTK2 was released because it changed stuff from GTK1, then they complained when GTK3 was released because it changed stuff from GTK2. It's totally understandable and normal for some to want to avoid or delay making the switch, but many others have been willing to make it for the improvements.
>Every attempt I've made to reach out to developers has either gone cold or been rejected. The current leadership has made it clear that they don't have my best interests at mind.
Well if you were on freenode then those probably weren't the upstream developers or any of the current project leadership so I think you might have a wrong impression; you're saying a whole lot of negative things but the underlying logic just doesn't really add up to me. I'm not interested to argue with you either, if you can just mention what the issue is with your app I might be able to help you.
>They'd rather scrap everything I used and promise a replacement instead of iterating on it or fixing it, which is unacceptable for a toolkit that is currently in active use.
This statement is also confusing to me, the replacement is the iteration and fixing. It's being worked on. It can't really be any other way, Glade is a very old application from the GNOME 1 days that's been continuously ported and it still inherits some old design flaws from that. To finally fix the design flaws the program needs some major breakage or a rewrite, so they decided to go with the rewrite because it's actually easier than hacking apart all the internals of Glade and breaking the whole program. And by "they" I mean the one person who has been working on Glade for the last few years and is now working on the replacement. I don't know what "promise" you're talking about either, I think it's a bad situation that only one person is working on this. He could stop working on it at any time and then you'd have no GUI builder at all, the "bus factor" on these projects is a concern right now.
>I refuse to donate my time or effort to people who disrespect me like that.
I'm not suggesting you do that, it seems more like you were asking about taking time or effort to fix your own application.
>There have always been apps more heavily integrated with GNOME vs GTK apps.
From my experience GTK2 apps were not "GNOME" apps, like there were many apps that did not installed the entire GNOME dependencies to work, I don't know if this changed lately since I so far only had the need for qt or GTK2 apps.
From my experience GTK2 apps were not "GNOME" apps, like there were many apps that did not installed the entire GNOME dependencies to work, I don't know if this changed lately since I so far only had the need for qt or GTK2 apps.
That's more because GNOME has completely dropped GTK2 while other projects continue to use it. In the past that wasn't true, GNOME 2 apps depended on a separate library called libgnomeui that had widgets specific to GNOME 2. All the actively-developed GNOME apps ported to GTK3 long ago and so they dropped that dependency which is why you don't see it anymore. The only apps left using GTK2 are non-GNOME apps and so they never depended on that in the first place.
>They're making their desktop environment and apps into a walled garden on a platform like Linux.
This is a rather empty statement as all these apps and the whole platform still continue to be open source.
>Call it what you want but they certainly don't intend to play nice with anyone and have adopted the approach of "my way or the highway"
I don't see how this is any different from how it was before. I've also found that KDE apps don't really work well outside of KDE, XFCE apps don't really work well outside of XFCE, etc. There is a clear line where an app developer has to decide if they're making a cross platform app (like LibreOffice, Blender, etc) or if they're making an app that integrates with a specific platform. Every single desktop I've ever seen has drawn this line somewhere because this is what users want, a KDE user prefers to use the KDE file manager and finds the GNOME file manager not so usable, a GNOME user prefers to use the GNOME file manager and finds the KDE file manager not so usable, etc.
>Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
I think you're confusing GTK4 with libadwaita, libadwaita is the library for GNOME apps that are only tested with GNOME and don't intend to be used outside it. GTK4 itself is not tied to any environment. And even then a developer could likely get libadwaita apps to work reasonably well in other environments with some porting work, similarly to how Krita depends on some KDE widgets and libraries but has been ported to other platforms.
>They also engage in carefully crafted doublespeak when it comes to things like extensions and user choice regarding configuration.
I don't understand, the stance on extensions has always been pretty obvious to me. Extensions are a third-party customization, they can work well and can do pretty much anything but because of that it's the user's responsibility to ensure their configuration is a working one.
This is a rather empty statement as all these apps and the whole platform still continue to be open source.
>Call it what you want but they certainly don't intend to play nice with anyone and have adopted the approach of "my way or the highway"
I don't see how this is any different from how it was before. I've also found that KDE apps don't really work well outside of KDE, XFCE apps don't really work well outside of XFCE, etc. There is a clear line where an app developer has to decide if they're making a cross platform app (like LibreOffice, Blender, etc) or if they're making an app that integrates with a specific platform. Every single desktop I've ever seen has drawn this line somewhere because this is what users want, a KDE user prefers to use the KDE file manager and finds the GNOME file manager not so usable, a GNOME user prefers to use the GNOME file manager and finds the KDE file manager not so usable, etc.
>Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
I think you're confusing GTK4 with libadwaita, libadwaita is the library for GNOME apps that are only tested with GNOME and don't intend to be used outside it. GTK4 itself is not tied to any environment. And even then a developer could likely get libadwaita apps to work reasonably well in other environments with some porting work, similarly to how Krita depends on some KDE widgets and libraries but has been ported to other platforms.
>They also engage in carefully crafted doublespeak when it comes to things like extensions and user choice regarding configuration.
I don't understand, the stance on extensions has always been pretty obvious to me. Extensions are a third-party customization, they can work well and can do pretty much anything but because of that it's the user's responsibility to ensure their configuration is a working one.
> as all these apps and the whole platform still continue to be open source.
I mean, what is that even meant to convey? Do you mean to say that one can always create hard forks of non-trivial packages like GTK or develop extensions for GNOME shell the change the way it works like the PopOS guys did? We all know how well that turned out.
> I've also found that KDE apps don't really work well outside of KDE
Funny, because I use i3wm on an old NAS and KDE apps like Spectacle, Gwenview, and Dolphin work fine and use whatever theme and font I tell them to use and don't make decisions for me by assuming I'm incapable of making them. Can't say the same for GTK4 GNOME apps. They're not built to be used outside GNOME because GNOME is now a "platform", which is just doublespeak for a walled garden.
> the stance on extensions has always been pretty obvious to me.
It's obvious to me as well — we don't care about GNOME extensions[^1]. It's rather unfortunate that the extension system exists at all. People waste so much time and resources on making elaborate extensions like the Pop Shell or Dash to Dock under the impression that their extensions are somehow welcome but then they have to keep fixing them after every new GNOME release. What's even worse is that unsuspecting users use these extensions.
[^1]: https://blogs.gnome.org/tbernard/2021/07/13/community-power-...
I mean, what is that even meant to convey? Do you mean to say that one can always create hard forks of non-trivial packages like GTK or develop extensions for GNOME shell the change the way it works like the PopOS guys did? We all know how well that turned out.
> I've also found that KDE apps don't really work well outside of KDE
Funny, because I use i3wm on an old NAS and KDE apps like Spectacle, Gwenview, and Dolphin work fine and use whatever theme and font I tell them to use and don't make decisions for me by assuming I'm incapable of making them. Can't say the same for GTK4 GNOME apps. They're not built to be used outside GNOME because GNOME is now a "platform", which is just doublespeak for a walled garden.
> the stance on extensions has always been pretty obvious to me.
It's obvious to me as well — we don't care about GNOME extensions[^1]. It's rather unfortunate that the extension system exists at all. People waste so much time and resources on making elaborate extensions like the Pop Shell or Dash to Dock under the impression that their extensions are somehow welcome but then they have to keep fixing them after every new GNOME release. What's even worse is that unsuspecting users use these extensions.
[^1]: https://blogs.gnome.org/tbernard/2021/07/13/community-power-...
>I mean, what is that even meant to convey?
I'm conveying that no party can actually restrict this, GNOME/KDE apps might look ugly and bad on the other desktop but that's different from a business/legal restriction stopping you from running it or even trying to improve the ugliness.
>Do you mean to say that one can always create hard forks of non-trivial packages like GTK or develop extensions for GNOME shell the change the way it works like the PopOS guys did?
Well they don't have to make a hard fork, downstreams can just apply a few modifications here and there like Ubuntu currently does. I think Pop!_OS was trying to do too much with a small team and that was where they ran into trouble, I'd expect their progress to be even slower if they try to develop their own desktop.
>Funny, because I use i3wm on an old NAS and KDE apps like Spectacle, Gwenview, and Dolphin work fine and use whatever theme and font I tell them to use
That's true you can get them to work but they're not ideal. Your use case seems to be unusual, an old FAQ entry suggests that i3wm users prefer text-based file managers: https://faq.i3wm.org/question/92/what-is-recommended-file-ma...
I've also had KDE apps break quite badly with certain themes so I don't really know what you mean they work fine. In my experience KDE apps only work flawlessly when using Breeze, some themes like Kvantum make heavy modifications to the apps and so can cause pretty bad breakage.
>Can't say the same for GTK4 GNOME apps. They're not built to be used outside GNOME because GNOME is now a "platform", which is just doublespeak for a walled garden.
No, KDE and GNOME were both platforms for some time. What that means is they provide certain services and APIs for app developers that you can't get without using those APIs. There is little overlap between them, but that doesn't make them a walled garden. Historically I don't think KDE/GNOME developers have ever spent much time testing KDE/GNOME programs outside their respective desktops. You can try to get them to work in something else like i3wm but it's always been on users of those other window managers to figure out how to integrate it. Why would they bother making a KDE or GNOME app if they don't intend for it to be used with that desktop? You're confusing a walled garden with a simple case of developer intent. A walled garden would be if the app developers were forced to use these APIs, but they are not; it's actually the opposite of that, app developers can use whatever they want and that's why you're having trouble getting something to integrate with another environment. Not every API can integrate with all potential environments.
>It's obvious to me as well — we don't care about GNOME extensions
It's worth noting that blog is one developer's opinion. Tobias is also not a shell developer and does not make decisions for shell developers on what to do about extensions. He is of course free to give his opinion on extensions, as are you.
>It's rather unfortunate that the extension system exists at all.
No, I think it would be worse if there would be no extensions. Then you'd have no way to modify the shell.
>People waste so much time and resources on making elaborate extensions under the impression that their extensions are somehow welcome but then they have to keep fixing them
This is a misconception. Some more complex extensions that modify the shell in complex ways do need to be fixed every release. But a large number of extensions don't need anything more than some minor changes or some testing and a version bump. There is also some efforts to reduce the amount of work needed by extension developers, you can read about it here: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-...
I'm conveying that no party can actually restrict this, GNOME/KDE apps might look ugly and bad on the other desktop but that's different from a business/legal restriction stopping you from running it or even trying to improve the ugliness.
>Do you mean to say that one can always create hard forks of non-trivial packages like GTK or develop extensions for GNOME shell the change the way it works like the PopOS guys did?
Well they don't have to make a hard fork, downstreams can just apply a few modifications here and there like Ubuntu currently does. I think Pop!_OS was trying to do too much with a small team and that was where they ran into trouble, I'd expect their progress to be even slower if they try to develop their own desktop.
>Funny, because I use i3wm on an old NAS and KDE apps like Spectacle, Gwenview, and Dolphin work fine and use whatever theme and font I tell them to use
That's true you can get them to work but they're not ideal. Your use case seems to be unusual, an old FAQ entry suggests that i3wm users prefer text-based file managers: https://faq.i3wm.org/question/92/what-is-recommended-file-ma...
I've also had KDE apps break quite badly with certain themes so I don't really know what you mean they work fine. In my experience KDE apps only work flawlessly when using Breeze, some themes like Kvantum make heavy modifications to the apps and so can cause pretty bad breakage.
>Can't say the same for GTK4 GNOME apps. They're not built to be used outside GNOME because GNOME is now a "platform", which is just doublespeak for a walled garden.
No, KDE and GNOME were both platforms for some time. What that means is they provide certain services and APIs for app developers that you can't get without using those APIs. There is little overlap between them, but that doesn't make them a walled garden. Historically I don't think KDE/GNOME developers have ever spent much time testing KDE/GNOME programs outside their respective desktops. You can try to get them to work in something else like i3wm but it's always been on users of those other window managers to figure out how to integrate it. Why would they bother making a KDE or GNOME app if they don't intend for it to be used with that desktop? You're confusing a walled garden with a simple case of developer intent. A walled garden would be if the app developers were forced to use these APIs, but they are not; it's actually the opposite of that, app developers can use whatever they want and that's why you're having trouble getting something to integrate with another environment. Not every API can integrate with all potential environments.
>It's obvious to me as well — we don't care about GNOME extensions
It's worth noting that blog is one developer's opinion. Tobias is also not a shell developer and does not make decisions for shell developers on what to do about extensions. He is of course free to give his opinion on extensions, as are you.
>It's rather unfortunate that the extension system exists at all.
No, I think it would be worse if there would be no extensions. Then you'd have no way to modify the shell.
>People waste so much time and resources on making elaborate extensions under the impression that their extensions are somehow welcome but then they have to keep fixing them
This is a misconception. Some more complex extensions that modify the shell in complex ways do need to be fixed every release. But a large number of extensions don't need anything more than some minor changes or some testing and a version bump. There is also some efforts to reduce the amount of work needed by extension developers, you can read about it here: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-...
> Your use case seems to be unusual, an old FAQ entry suggests that i3wm users prefer text-based file managers:
This is an old NAS that I don't really use much.
It's true though, I've mostly stopped using GUI apps on my primary workstation except Firefox because of how messy the situation is with GUIs on Linux. GTK wants to enforce its decisions on me and KDE Qt apps don't work well on my Wayland window manager.
> I've also had KDE apps break quite badly with certain themes so I don't really know what you mean they work fine.
I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps. I'm not using Android or iOS so I don't expect to be treated like an idiot.
> You can try to get them to work in something else like i3wm but it's always been on users of those other window managers to figure out how to integrate it.
It's not the uphill battle you're trying to project to make KDE apps work on non-KDE environment. Sure, some themes aren't built well but some are and all I have to do is install Kvantum+qt5ct to make the app look how I want it to. This isn't possible with GNOME and elementary apps because they chose to become their own isolated silos.
> It's worth noting that blog is one developer's opinion.
Is it? The opinions on that article are almost always shared by all the core GNOME developers I've seen commenting on issue trackers. Even the stopthemingmyapp guys resonate those opinions.
Doesn't sound like "one developer's opinion" to me.
> No, I think it would be worse if there would be no extensions.
Judging by the general disdain towards extensions by GNOME developers and many users, I doubt that's the case.
This is an old NAS that I don't really use much.
It's true though, I've mostly stopped using GUI apps on my primary workstation except Firefox because of how messy the situation is with GUIs on Linux. GTK wants to enforce its decisions on me and KDE Qt apps don't work well on my Wayland window manager.
> I've also had KDE apps break quite badly with certain themes so I don't really know what you mean they work fine.
I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps. I'm not using Android or iOS so I don't expect to be treated like an idiot.
> You can try to get them to work in something else like i3wm but it's always been on users of those other window managers to figure out how to integrate it.
It's not the uphill battle you're trying to project to make KDE apps work on non-KDE environment. Sure, some themes aren't built well but some are and all I have to do is install Kvantum+qt5ct to make the app look how I want it to. This isn't possible with GNOME and elementary apps because they chose to become their own isolated silos.
> It's worth noting that blog is one developer's opinion.
Is it? The opinions on that article are almost always shared by all the core GNOME developers I've seen commenting on issue trackers. Even the stopthemingmyapp guys resonate those opinions.
Doesn't sound like "one developer's opinion" to me.
> No, I think it would be worse if there would be no extensions.
Judging by the general disdain towards extensions by GNOME developers and many users, I doubt that's the case.
BTW for an example, here is what the KDE system settings looks like for me when I try to run it using qt5ct in GNOME: https://i.imgur.com/pxEKXye.png
I think we can agree that this is unusable, it also appears that it is attempting to load 3 or 4 themes at the same time which are all conflicting with each other. To me, trying to run KDE apps with a GNOME style or GNOME apps with a KDE style has always been a risky endeavor. Perhaps you got lucky running some apps that played nicely with themes but some apps just don't work at all outside their intended environment because they were not designed to use themes.
I think we can agree that this is unusable, it also appears that it is attempting to load 3 or 4 themes at the same time which are all conflicting with each other. To me, trying to run KDE apps with a GNOME style or GNOME apps with a KDE style has always been a risky endeavor. Perhaps you got lucky running some apps that played nicely with themes but some apps just don't work at all outside their intended environment because they were not designed to use themes.
> BTW for an example, here is what the KDE system settings looks like for me when I try to run it using qt5ct in GNOME: https://i.imgur.com/pxEKXye.png
I don't get why you'd want to run KDE system settings outside KDE. The system settings app also has a lot of optional dependencies. I don't know which distro you're using but if any of those optional dependencies isn't installed, the system settings app misbehaves.
Typically, you'd run apps like Spectacle and Gwenview and Dolphin, standalone apps that serve a purpose, and from my experience, those have always worked on i3wm without issues.
I don't get why you'd want to run KDE system settings outside KDE. The system settings app also has a lot of optional dependencies. I don't know which distro you're using but if any of those optional dependencies isn't installed, the system settings app misbehaves.
Typically, you'd run apps like Spectacle and Gwenview and Dolphin, standalone apps that serve a purpose, and from my experience, those have always worked on i3wm without issues.
Well again that's great for you that all the apps you use worked, but a lot of the KDE apps I use are broken with some themes :) I'm sure they would work fine in i3wm if you used Breeze but I have had very mixed results on any window manager with qt5ct, some apps play nice with it and some don't. It's not just the system settings that are broken for me, I just picked that as an example. Sometimes it's useful outside of KDE because it's the best way to configure global settings for some KDE apps, not just the shell and window manager. I've looked into it and it has nothing to do with optional dependencies, there are actually just issues with some themes and some apps.
But generally I think it's a bad idea to try to run any KDE apps outside KDE, or any GNOME apps outside GNOME, etc, those apps work much better when used with their respective desktops.
But generally I think it's a bad idea to try to run any KDE apps outside KDE, or any GNOME apps outside GNOME, etc, those apps work much better when used with their respective desktops.
>I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps.
Well you can also use any theme you want on GNOME apps, libadwaita didn't break that, or rather it's just as bad as it is with KDE themes. Some themes will work but other themes will break everything.
>It's not the uphill battle you're trying to project to make KDE apps work on non-KDE environment. Sure, some themes aren't built well but some are and all I have to do is install Kvantum+qt5ct to make the app look how I want it to.
I can't agree here, I have had qt5ct break really badly with some apps and themes. It just doesn't work if the app wasn't designed to use it. I don't even bother with KDE themes anymore and I just use Breeze, if you ask me third-party theming is a total waste of time on any platform. For me it's always broken things or caused very strange glitches.
>I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps. This isn't possible with GNOME and elementary apps because they chose to become their own isolated silos.
Again I honestly have no idea what you're talking about here, GNOME and Elementary apps can still be themed through unofficial third party methods. Developers of apps for those platforms do tend to focus on supporting the official theme for those platforms but that's the same as KDE where developers focus on supporting Breeze.
>I'm not using Android or iOS so I don't expect to be treated like an idiot.
Funny you mention this because I used to have jailbroken Android and iOS phones that were hacked to install third-party themes. The themes were just as broken as with GNOME and KDE. They might work OK with some of the built-in apps but would break quite badly with any third-party apps or when an OS update happened. That was another reason I just stopped trying to use third-party themes altogether.
>Is it? The opinions on that article are almost always shared by all the core GNOME developers I've seen commenting on issue trackers. Even the stopthemingmyapp guys resonate those opinions.
I'm not sure what you mean by core GNOME developers. IIRC Stopthemingmy.app was signed by some independent developers that decided they don't want to support third party themes that break their apps. It's not even related to the shell or extensions. You're conflating several things here. That petition didn't change anything technically about themes, it was a public acknowledgement that themes can break apps badly and that they won't be supporting them, which they never did before anyway.
>Judging by the general disdain towards extensions by GNOME developers and many users, I doubt that's the case.
You may have a biased view, I've heard complaints but the reason they happen is because users really like extensions and want them to stay. I've also heard lots of good things from users and extension developers, it works well when extension developers can test and update their extensions in a timely manner. Besides you can already have that if you want; just don't install any extensions.
Well you can also use any theme you want on GNOME apps, libadwaita didn't break that, or rather it's just as bad as it is with KDE themes. Some themes will work but other themes will break everything.
>It's not the uphill battle you're trying to project to make KDE apps work on non-KDE environment. Sure, some themes aren't built well but some are and all I have to do is install Kvantum+qt5ct to make the app look how I want it to.
I can't agree here, I have had qt5ct break really badly with some apps and themes. It just doesn't work if the app wasn't designed to use it. I don't even bother with KDE themes anymore and I just use Breeze, if you ask me third-party theming is a total waste of time on any platform. For me it's always broken things or caused very strange glitches.
>I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps. This isn't possible with GNOME and elementary apps because they chose to become their own isolated silos.
Again I honestly have no idea what you're talking about here, GNOME and Elementary apps can still be themed through unofficial third party methods. Developers of apps for those platforms do tend to focus on supporting the official theme for those platforms but that's the same as KDE where developers focus on supporting Breeze.
>I'm not using Android or iOS so I don't expect to be treated like an idiot.
Funny you mention this because I used to have jailbroken Android and iOS phones that were hacked to install third-party themes. The themes were just as broken as with GNOME and KDE. They might work OK with some of the built-in apps but would break quite badly with any third-party apps or when an OS update happened. That was another reason I just stopped trying to use third-party themes altogether.
>Is it? The opinions on that article are almost always shared by all the core GNOME developers I've seen commenting on issue trackers. Even the stopthemingmyapp guys resonate those opinions.
I'm not sure what you mean by core GNOME developers. IIRC Stopthemingmy.app was signed by some independent developers that decided they don't want to support third party themes that break their apps. It's not even related to the shell or extensions. You're conflating several things here. That petition didn't change anything technically about themes, it was a public acknowledgement that themes can break apps badly and that they won't be supporting them, which they never did before anyway.
>Judging by the general disdain towards extensions by GNOME developers and many users, I doubt that's the case.
You may have a biased view, I've heard complaints but the reason they happen is because users really like extensions and want them to stay. I've also heard lots of good things from users and extension developers, it works well when extension developers can test and update their extensions in a timely manner. Besides you can already have that if you want; just don't install any extensions.
> Well you can also use any theme you want on GNOME apps, libadwaita didn't break that
Happy to correct myself but unless there's a supported way to change themes for libadwaita apps using GNOME tweak tool or something similar, this is just doublespeak.
For example, I wasn't able to change the theme of this app using GNOME Tweak Tool the last time I tried.
https://gitlab.gnome.org/World/Shortwave
Happy to correct myself but unless there's a supported way to change themes for libadwaita apps using GNOME tweak tool or something similar, this is just doublespeak.
For example, I wasn't able to change the theme of this app using GNOME Tweak Tool the last time I tried.
https://gitlab.gnome.org/World/Shortwave
I think you are misusing the word "doublespeak", I would suggest against using that word. There are some technical reasons why tweak tool will not work anymore but you can still use gtk.css and GTK_THEME, see here: https://blogs.gnome.org/alatiera/2021/09/18/the-truth-they-a...
Worst case it is the same as KDE, you have to set some environment variables and it still may not work correctly with some apps because third-party theming is inherently unreliable. The tweak tool method was also an unsupported third-party thing with most of the same limitations. It has been in a broken state for a while but you probably just didn't notice it because you weren't unlucky enough to end up in a situation where it affected you.
I'd still like to emphasize my other comments though, third-party theming is quite broken on every single platform I've ever used and I suggest against using it if you want to avoid apps randomly breaking. If you plan to continue that route then you may have to get more involved in development to the point where you can fix theme bugs and patch the apps without asking other people for help. That's been my experience with third-party themes anyway, they are essentially hacking the apps and so are not really for average users to mess with.
Worst case it is the same as KDE, you have to set some environment variables and it still may not work correctly with some apps because third-party theming is inherently unreliable. The tweak tool method was also an unsupported third-party thing with most of the same limitations. It has been in a broken state for a while but you probably just didn't notice it because you weren't unlucky enough to end up in a situation where it affected you.
I'd still like to emphasize my other comments though, third-party theming is quite broken on every single platform I've ever used and I suggest against using it if you want to avoid apps randomly breaking. If you plan to continue that route then you may have to get more involved in development to the point where you can fix theme bugs and patch the apps without asking other people for help. That's been my experience with third-party themes anyway, they are essentially hacking the apps and so are not really for average users to mess with.
> The tweak tool method was also an unsupported third-party thing with most of the same limitations.
Interesting, so what was and is the supported first party method to change themes and set keyboard shortcuts and use Emacs keybindings and make the Caps Lock key behave as Esc on GNOME?
Interesting, so what was and is the supported first party method to change themes and set keyboard shortcuts and use Emacs keybindings and make the Caps Lock key behave as Esc on GNOME?
>which is just doublespeak for a walled garden.
This is horse shit at best, social espionage at the other end. You are intentionally misusing this term.
Your data and the source can be used in any way you as the user sees fit.
It can be forked, it can be changed, your freedoms are enforced.
This is horse shit at best, social espionage at the other end. You are intentionally misusing this term.
Your data and the source can be used in any way you as the user sees fit.
It can be forked, it can be changed, your freedoms are enforced.
> It can be forked, it can be changed, your freedoms are enforced.
Sure, let's pretend that every user is a programmer who knows what a hard fork is and, even if he is a programmer, he's willing to create hard forks of each and every GNOME software he uses to support features that worked before and don't work now. This has worked out great for PopOS and Budgie right?
It's so much easier to just fall back on the open source argument and ignore the fact that it means nothing for the average user who doesn't know the first thing about C code or git to be able to make the changes he wants to.
Sure, let's pretend that every user is a programmer who knows what a hard fork is and, even if he is a programmer, he's willing to create hard forks of each and every GNOME software he uses to support features that worked before and don't work now. This has worked out great for PopOS and Budgie right?
It's so much easier to just fall back on the open source argument and ignore the fact that it means nothing for the average user who doesn't know the first thing about C code or git to be able to make the changes he wants to.
It's not clear what you're talking about because there isn't a reality where this does whatever you want without programmers working on it. Average users are always going to need help from them, regardless of whether it's upstream or a hard fork. That choice also doesn't seem to be relevant to Pop!_OS and Budgie because for them it was a choice between hard fork or start from scratch, which is primarily a technical choice which needs experienced programmers either way.
> there isn't a reality where this does whatever you want
I wish something called user choice and configuration options existed in this reality.
I wish something called user choice and configuration options existed in this reality.
There are multiple ways to get that though. One of them would be if a lot of hard forks existed, then you'd have a lot of options to choose from. Or those developers can contribute upstream and work on adding tons of options to the upstream project. My point is that there isn't a world where you just get the choice and options out of thin air without programmers, eventually someone has to program the options in somewhere or they just won't exist.
Honestly, I think they are going in the right direction.
The main problem with the Linux desktop has always been the insane fragmentation in my opinion. There's a million different options for every little thing and so developers don't have a platform they can count on and their option is to either provide reduced functionality (no integration with the desktop environment) or support a bunch of different things. And users don't get a polished JustWorks(TM) desktop experience.
The main problem with the Linux desktop has always been the insane fragmentation in my opinion. There's a million different options for every little thing and so developers don't have a platform they can count on and their option is to either provide reduced functionality (no integration with the desktop environment) or support a bunch of different things. And users don't get a polished JustWorks(TM) desktop experience.
> even distros like NixOS encourage users to use GNOME, which is absolutely insane when you think about it.
? NixOS doesn't have a default desktop environment. At the same time, the graphical installation media images have always come with Plasma as long as I can remember, and the example desktop environment commented out in the template given by nixos-generate-config has likewise always been Plasma.
? NixOS doesn't have a default desktop environment. At the same time, the graphical installation media images have always come with Plasma as long as I can remember, and the example desktop environment commented out in the template given by nixos-generate-config has likewise always been Plasma.
I'm taking about the "Recommended for most users" tag for the GNOME ISO.
https://nixos.org/download.html#nixos-iso
https://nixos.org/download.html#nixos-iso
Wow! I can't believe I've never noticed that. For many years, the only graphical installation disk was based on Plasma, and I think it also had that tag. NixOS only started shipping a GNOME iso for installation purposes a little over a year ago (for 20.09), and I kinda never noticed.
Looks like the main reason GNOME is recommended for installation media at the moment is that it does a better job of autodetecting HiDPI displays, and then scaling appropriately: https://github.com/NixOS/nixos-homepage/pull/643
There are also some packaging issues for Qt with NixOS, because Qt plugins fundamentally rely on ‘impurity’ at runtime, and the Qt framework makes promises it doesn't keep about binary compatibility.
Here are some of the relevant issues for historical context and some of the tradeoffs Nixpkgs developers have faced when it comes to handling Qt and KDE packaging:
https://github.com/NixOS/nixpkgs/issues/86369
https://github.com/NixOS/nixpkgs/pull/54525
https://github.com/NixOS/nixpkgs/pull/44047
I realize that may not be a fully satisfying answer as to why the GNOME-based installation graphical ISO is recommended over the Qt one because one can imagine that the Qt packaging issue should be resolved some other way, or see the difficulty of packaging Qt plugins and applications in Nixpkgs as fundamentally a Nix defect. But I hope it makes that decision make more sense.
FWIW, afaict Plasma is the more popular of the two major DEs on NixOS, and it's what I've always used on NixOS myself, including now. It is definitely usable.
Looks like the main reason GNOME is recommended for installation media at the moment is that it does a better job of autodetecting HiDPI displays, and then scaling appropriately: https://github.com/NixOS/nixos-homepage/pull/643
There are also some packaging issues for Qt with NixOS, because Qt plugins fundamentally rely on ‘impurity’ at runtime, and the Qt framework makes promises it doesn't keep about binary compatibility.
Here are some of the relevant issues for historical context and some of the tradeoffs Nixpkgs developers have faced when it comes to handling Qt and KDE packaging:
https://github.com/NixOS/nixpkgs/issues/86369
https://github.com/NixOS/nixpkgs/pull/54525
https://github.com/NixOS/nixpkgs/pull/44047
I realize that may not be a fully satisfying answer as to why the GNOME-based installation graphical ISO is recommended over the Qt one because one can imagine that the Qt packaging issue should be resolved some other way, or see the difficulty of packaging Qt plugins and applications in Nixpkgs as fundamentally a Nix defect. But I hope it makes that decision make more sense.
FWIW, afaict Plasma is the more popular of the two major DEs on NixOS, and it's what I've always used on NixOS myself, including now. It is definitely usable.
> But I hope it makes that decision make more sense.
It does but it's rather unfortunate that the only choice we have when it comes to DEs is either GNOME, which is built by a group of arrogant developers who think there is no downstream for GNOME and GTK, and KDE, which has technical issues that prevent widespread adoption.
It does but it's rather unfortunate that the only choice we have when it comes to DEs is either GNOME, which is built by a group of arrogant developers who think there is no downstream for GNOME and GTK, and KDE, which has technical issues that prevent widespread adoption.
I think you're misinterpreting decisiveness as arrogance. GNOME developers would probably like to respond to more of them but they can't because of lack of developers, so they have to make tough decisions about what to support. When downstreams don't handle some of the burden then it's a loss for everybody. KDE also does not really like or benefit from having a ton of downstream forks either, the project is way too large and it's more useful to get upstream contributions. Maybe it would be better if there were more choices, but nothing is perfect. You and I could probably find more things to complain about in any third/fourth/fifth choice.
>and KDE, which has technical issues that prevent widespread adoption
Which KDE technical issues are preventing its adoption? I'm running KDE full for a long time and encountered no issues.
IMHO, the lack of KDE adoption is the inertia of GNOME adoption by the major distros combined with the inertia of hate over KDE with the stereotype that "it's bloated" which hasn't really been the case in the last versions of Plasma.
Which KDE technical issues are preventing its adoption? I'm running KDE full for a long time and encountered no issues.
IMHO, the lack of KDE adoption is the inertia of GNOME adoption by the major distros combined with the inertia of hate over KDE with the stereotype that "it's bloated" which hasn't really been the case in the last versions of Plasma.
> Which KDE technical issues are preventing its adoption? I'm running KDE full for a long time and encountered no issues.
Some of them are linked by pxc post above mine.
There's also the issue that Qt apps can only be written in C++, a language that many don't want anything to do with. In comparison, GTK has bindings for a variety of languages including Rust.
Some of them are linked by pxc post above mine.
There's also the issue that Qt apps can only be written in C++, a language that many don't want anything to do with. In comparison, GTK has bindings for a variety of languages including Rust.
>In comparison, GTK has bindings for a variety of languages including Rust.
Are those good bindings , or auto-generated or outdated ones ? I did not checked in a long time but I think only Python had decent bindings. I would avoid non-official bindings, those are most of the time garbage and you waste your time instead of focusing on your work.
I seen Qt in a lot of proprietary applications, including launchers for video games (the app that will let you setup a game configuration before launch) - I was surprised why a Windows only video game would not use the Windows APi directly, but it is obvious that Qt is better then whatever Windows has this days for c++ devs and game devs are not afraid of a bit of c++ or have some irrational disgust for Qt pre-procesor (I see this excuse all the time, we don't switch from GTK to Qt because of the qmake/moc I honestly prefer an honest explanation)
Are those good bindings , or auto-generated or outdated ones ? I did not checked in a long time but I think only Python had decent bindings. I would avoid non-official bindings, those are most of the time garbage and you waste your time instead of focusing on your work.
I seen Qt in a lot of proprietary applications, including launchers for video games (the app that will let you setup a game configuration before launch) - I was surprised why a Windows only video game would not use the Windows APi directly, but it is obvious that Qt is better then whatever Windows has this days for c++ devs and game devs are not afraid of a bit of c++ or have some irrational disgust for Qt pre-procesor (I see this excuse all the time, we don't switch from GTK to Qt because of the qmake/moc I honestly prefer an honest explanation)
I get the impression that GTK+'s Vala and Python bindings are good. Idk about Rust
I don’t know the intricacies of the politics at play here, so could you explain why this is “insane”?
I guess this is just my opinion but NixOS is probably the most esoteric Linux distribution I've used. Anyone who intends to use NixOS comfortably probably isn't apprehensive about configuration and customization, things which are the antithesis of everything GNOME stands for.
I fail to see why GNOME, or any DE for that matter, is something that should be recommended by a distribution like NixOS.
I fail to see why GNOME, or any DE for that matter, is something that should be recommended by a distribution like NixOS.
Being the default and thereby “recommended” desktop in NixOS a lot different than in other distro’s.
In other distro’s, to get a non-default desktop, you have to download a whole different distro “spin”, like Kubuntu. Or add the new desktop packages and manually configure them all.
With NixOS you use the same install image, and just change two or three lines in the master configuration.nix file, and re/build. You can change back and forth between DE’s that use different window managers with a reboot, or between DE’s that use the same window manager with a relog [3].
Most the major desktops are supported in NixOS [1][2]. Gnome being the default means little, is easy to change should NixOS community ever form a consensus about changing the default (say in response to Gnome crossing some line), and is easy for end users to change any time.
——
# Gnome
services.xserver.enable = true;
services.xserver.displayManager.gdm.enable = true;
services.xserver.desktopManager.gnome.enable = true;
——
# KDE
services.xserver.enable = true;
services.xserver.displayManager.sddm.enable = true;
services.xserver.desktopManager.plasma5.enable = true;
——
[1]:More info: https://nixos.org/manual/nixos/stable/index.html#sec-x11
[2]:Supported desktops: https://search.nixos.org/options?channel=21.11&from=0&size=5...
[3]:https://www.reddit.com/r/NixOS/comments/otnfq6/i3_or_sway_wh...
In other distro’s, to get a non-default desktop, you have to download a whole different distro “spin”, like Kubuntu. Or add the new desktop packages and manually configure them all.
With NixOS you use the same install image, and just change two or three lines in the master configuration.nix file, and re/build. You can change back and forth between DE’s that use different window managers with a reboot, or between DE’s that use the same window manager with a relog [3].
Most the major desktops are supported in NixOS [1][2]. Gnome being the default means little, is easy to change should NixOS community ever form a consensus about changing the default (say in response to Gnome crossing some line), and is easy for end users to change any time.
——
# Gnome
services.xserver.enable = true;
services.xserver.displayManager.gdm.enable = true;
services.xserver.desktopManager.gnome.enable = true;
——
# KDE
services.xserver.enable = true;
services.xserver.displayManager.sddm.enable = true;
services.xserver.desktopManager.plasma5.enable = true;
——
[1]:More info: https://nixos.org/manual/nixos/stable/index.html#sec-x11
[2]:Supported desktops: https://search.nixos.org/options?channel=21.11&from=0&size=5...
[3]:https://www.reddit.com/r/NixOS/comments/otnfq6/i3_or_sway_wh...
all you have to do is e.g.
sudo apt-get install cinnamon
on ubuntu, and then select cinnamon at the login screen after booting, and it'll work just fine. same for mate, plasma, etc. Same for debian, and most linux distros I've tried. installing another desktop isn't difficult at all, usually
sudo apt-get install cinnamon
on ubuntu, and then select cinnamon at the login screen after booting, and it'll work just fine. same for mate, plasma, etc. Same for debian, and most linux distros I've tried. installing another desktop isn't difficult at all, usually
Debian (and Ubuntu as a result) has "task-*-desktop" tasks (meta-packages) which install, configure and tune the whole distro for a new/additional desktop environment too.
I wasn't questioning NixOS's customisability. I was questioning the choice to promote GNOME as "recommended for most users" on the download page.
https://nixos.org/download.html#nixos-iso
There's no need for a distro like NixOS to do this. It only serves to lend weight to the arrogance displayed by GNOME.
https://nixos.org/download.html#nixos-iso
There's no need for a distro like NixOS to do this. It only serves to lend weight to the arrogance displayed by GNOME.
Right, and I'm pretty sure you can use the same display manager with both (at least if it's lightdm), and then switching back and forth between gnome and KDE is literally a matter of switching between the words "gnome" to "plasma5" in one place.
> Just because you disagree with them, it doesn't make them the "bad guys".
Since the KDE 3.5.x days, it's always KDE guys who try to build corresponding GTK themes of the themes they default on the corresponding release, or build corresponding Qt themes of the GTK themes put forward as default by the GNOME guys.
Moreover, there are always ways to make GNOME subsystems work well on KDE systems, and KDE guys always make sure that the standards they propose work with the GNOME without much hassle. Also, KDE guys put forward cross-DE ways to make user experience better (XDG base folder specification, for example).
OTOH, GNOME people sit on their high thrones like they're the only game in town. I respect them deeply, but I can't appreciate them just because they auto-generated their JS introspection layer from C code automatically, but didn't bother to write any documentation, because you can try it all in the built-in JS console.
I have a couple of more, lower level stories with them, which caused a lot of all-nighters and project postponements, but that's for another comment.
Their attitude is not helpful.
Since the KDE 3.5.x days, it's always KDE guys who try to build corresponding GTK themes of the themes they default on the corresponding release, or build corresponding Qt themes of the GTK themes put forward as default by the GNOME guys.
Moreover, there are always ways to make GNOME subsystems work well on KDE systems, and KDE guys always make sure that the standards they propose work with the GNOME without much hassle. Also, KDE guys put forward cross-DE ways to make user experience better (XDG base folder specification, for example).
OTOH, GNOME people sit on their high thrones like they're the only game in town. I respect them deeply, but I can't appreciate them just because they auto-generated their JS introspection layer from C code automatically, but didn't bother to write any documentation, because you can try it all in the built-in JS console.
I have a couple of more, lower level stories with them, which caused a lot of all-nighters and project postponements, but that's for another comment.
Their attitude is not helpful.
Right.
What actually makes them the bad guys is that they parlayed the goodwill of the original GNOME (2 and prior) which was very open to change and community contribution into the restrictive community hostile thing that it is today.
I don't mind that it exists, but they should have changed the name and been more clear about the direction.
And should just be less obnoxious all around.
What actually makes them the bad guys is that they parlayed the goodwill of the original GNOME (2 and prior) which was very open to change and community contribution into the restrictive community hostile thing that it is today.
I don't mind that it exists, but they should have changed the name and been more clear about the direction.
And should just be less obnoxious all around.
Good point which I hadn't thought of. I really like GNOME 4 for my own workflow, but it doesn't have much in common with GNOME 2.
MATE is carrying on the torch
I would agree if
a. Their development team was more professional (locking threads when feedback starts coming in, making offhand derogatory comments about people's reading comprehension skills, trying to minimize serious problems to avoid dealing with merge requests/more work, blaming downstream actors like PopOS! for simply using their software and disagreeing with their ethos, etc.)
b. They used their funding to actually fix issues (GTK4 still has text rendering issues. 8 months later. Insert obligatory "thumbnail file picker" comment here)
c. They didn't regress features that previously worked (No more extensions, no more desktop tweaks, overall fewer settings in new releases, design upgrades that are decidedly opinionated)
d. They didn't treat their opinions as gospel (eg. encouraging Flatpak-or-die culture when Flatpak itself is still in it's infancy and wildly unstable, going out of their way to obfuscate theming interfaces, having "one guy" come up with a new design for something and implementing it before the community decides if it's something they want)
Yeah, I think I am comfortable calling them "the bad guys" in the current landscape of Linux. GTK's team is still fine (barely) but the overall effort to combine the two, add middleware like libadwaita, move fast and break things, and blame it on the user when things stop working is just getting to be asinine.
They can have a vision if they want, but it shouldn't have to come at the expanse of the rest of the community. That's how you burn goodwill.
a. Their development team was more professional (locking threads when feedback starts coming in, making offhand derogatory comments about people's reading comprehension skills, trying to minimize serious problems to avoid dealing with merge requests/more work, blaming downstream actors like PopOS! for simply using their software and disagreeing with their ethos, etc.)
b. They used their funding to actually fix issues (GTK4 still has text rendering issues. 8 months later. Insert obligatory "thumbnail file picker" comment here)
c. They didn't regress features that previously worked (No more extensions, no more desktop tweaks, overall fewer settings in new releases, design upgrades that are decidedly opinionated)
d. They didn't treat their opinions as gospel (eg. encouraging Flatpak-or-die culture when Flatpak itself is still in it's infancy and wildly unstable, going out of their way to obfuscate theming interfaces, having "one guy" come up with a new design for something and implementing it before the community decides if it's something they want)
Yeah, I think I am comfortable calling them "the bad guys" in the current landscape of Linux. GTK's team is still fine (barely) but the overall effort to combine the two, add middleware like libadwaita, move fast and break things, and blame it on the user when things stop working is just getting to be asinine.
They can have a vision if they want, but it shouldn't have to come at the expanse of the rest of the community. That's how you burn goodwill.
> GTK's team is still fine (barely)
Really? Isn't GTK where the CSD (client side decoration) is being forced onto every app, with no way to use native/normal window manager borders? It seems rather widely despised:
https://news.ycombinator.com/item?id=16241923
https://old.reddit.com/r/xfce/comments/lcj7cq/why_is_csd_bad...
Really? Isn't GTK where the CSD (client side decoration) is being forced onto every app, with no way to use native/normal window manager borders? It seems rather widely despised:
https://news.ycombinator.com/item?id=16241923
https://old.reddit.com/r/xfce/comments/lcj7cq/why_is_csd_bad...
That's more of a GNOME effort, if I'm being honest. It's a feature that's provided via GTK's libraries, but the whole "we're going to add CSD and you're not going to do anything about it" has been more of a GNOME sentiment[0].
[0] https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
[0] https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
App developers will design their apps in a certain way and will add features that they think benefits the app. Some will add CSD if they think it's beneficial and others won't. What is it that you would want to do about that? That's always been how it is. If you were in charge of designing the app then you'd be the one going to meetings and writing the code.
>Isn't GTK where the CSD (client side decoration) is being forced onto every app
No. GTK doesn't have any preference for decorations, you can use either one when writing GTK apps: https://docs.gtk.org/gtk4/method.Window.set_decorated.html
The app developer gets to choose what decorations they support. Some app developers will choose to only support a certain type of decorations; that's an intentional design decision made as part of the app. In the past, GNOME app developers have chosen to use CSD and XFCE developers didn't, but there seems to be a shift from them towards CSD too. I've also seen some XFCE users saying they like the CSD.
No. GTK doesn't have any preference for decorations, you can use either one when writing GTK apps: https://docs.gtk.org/gtk4/method.Window.set_decorated.html
The app developer gets to choose what decorations they support. Some app developers will choose to only support a certain type of decorations; that's an intentional design decision made as part of the app. In the past, GNOME app developers have chosen to use CSD and XFCE developers didn't, but there seems to be a shift from them towards CSD too. I've also seen some XFCE users saying they like the CSD.
Maybe the people that don't mind, or like it keep more quiet.
I prefer it, been a CSD user since before CSD itself, with Winamps rolled up UI.
>I prefer it, been a CSD user since before CSD itself, with Winamps rolled up UI.
That is it, but somehow you don't see it??? I mean is so obvious/// You could have Winamp or you could have an application with a window in the form of a circle but this days GNOME decided that you can ONLY have CSD and old apps that use SSD or non-GNOME apps that use SSD should switch to SSD... so you ahve 2 issues
1 GNOME is removing the option to have both SSD and CSD , and forces you into CSD only
2 GNOME does not provide(maybe things changed and someone forced those arrogant bastards to support some legacy app that RedHat needs) any support for SSD apps.
That is it, but somehow you don't see it??? I mean is so obvious/// You could have Winamp or you could have an application with a window in the form of a circle but this days GNOME decided that you can ONLY have CSD and old apps that use SSD or non-GNOME apps that use SSD should switch to SSD... so you ahve 2 issues
1 GNOME is removing the option to have both SSD and CSD , and forces you into CSD only
2 GNOME does not provide(maybe things changed and someone forced those arrogant bastards to support some legacy app that RedHat needs) any support for SSD apps.
I don't understand how you're having those issues. GNOME has never had the option to have both CSD and SSD. When GNOME apps used GTK2, SSD was the only option. When GNOME apps started moving towards GTK3, CSD became the only option. What you're asking for is a new feature because GNOME never supported both.
Legacy apps using X11 will use the legacy X11 decorations. Those should still work. For Wayland apps, those were never working correctly if they didn't support CSD. What you're again asking for is a new feature, there are no legacy Wayland apps that will depend on that functionality because it never existed in GNOME Wayland.
Legacy apps using X11 will use the legacy X11 decorations. Those should still work. For Wayland apps, those were never working correctly if they didn't support CSD. What you're again asking for is a new feature, there are no legacy Wayland apps that will depend on that functionality because it never existed in GNOME Wayland.
> SSD was the only option. When GNOME apps started moving towards GTK3, CSD became the only option. What you're asking for is a new feature because GNOME never supported both.
Really? , You should just hide the Window titlebar , and paint your own CSD, titlebars were not forced on you https://developer.gimp.org/api/2.0/gtk/GtkWindow.html#gtk-wi... , this is how for example splashscreens are implemented or fancy non rectangular windows , but to be honest I am not 100% sure if GNOME2 was also an asshold and disabled this GTK feature just to be spacial, if you can confirm then let me know if I am right then you need to acknowledge the fact that SSD was not forced on you(not Qt,not GTK, not even Windows/OSX forced SSD on you )
Really? , You should just hide the Window titlebar , and paint your own CSD, titlebars were not forced on you https://developer.gimp.org/api/2.0/gtk/GtkWindow.html#gtk-wi... , this is how for example splashscreens are implemented or fancy non rectangular windows , but to be honest I am not 100% sure if GNOME2 was also an asshold and disabled this GTK feature just to be spacial, if you can confirm then let me know if I am right then you need to acknowledge the fact that SSD was not forced on you(not Qt,not GTK, not even Windows/OSX forced SSD on you )
Sure, the feature existed in GTK but what I mean there is that GNOME 2 apps didn't use that. They never painted their own CSD. Sure some apps did for splash screens but not for ordinary app windows. Then when GNOME 3 happened they all redesigned their apps to only use CSD. They didn't implement SSD in Wayland because it wasn't part of the design and by then all the GNOME 2 apps were already gone anyway. That API is even still present in GTK4, the reason you saw a change is because the apps (the callers of the API) changed how they use it.
But the issue we have with GNOME is not that they changed their own apps to CSD,
the issue is that their Window Manager does not paint the SSD for non-GNOME app, I hope this is clear now or let me try to simplify it
Before
- you could have both CSD and SSD application run on GNOME
After
- you are FORCED to implement CSD on GNOME because their Window Manager will not paint the SSD for you, even for old application that existed before GNOME3 was created.
It would make sense for GNOME to support this old applications or toolkits that do not implement CSD , I really hope sanity will prevail over designer ego (it happened at Apple so there is a chance it will happen at GNOME after a few years of feedback)
Before
- you could have both CSD and SSD application run on GNOME
After
- you are FORCED to implement CSD on GNOME because their Window Manager will not paint the SSD for you, even for old application that existed before GNOME3 was created.
It would make sense for GNOME to support this old applications or toolkits that do not implement CSD , I really hope sanity will prevail over designer ego (it happened at Apple so there is a chance it will happen at GNOME after a few years of feedback)
>you are FORCED to implement CSD on GNOME because their Window Manager will not paint the SSD for you, even for old application that existed before GNOME3 was created.
No, this is not true at all. Old applications and toolkits that existed before GNOME 3 was created will use X11, and the legacy decorations will still work there.
No, this is not true at all. Old applications and toolkits that existed before GNOME 3 was created will use X11, and the legacy decorations will still work there.
Yeah, that goes against everything Wayland.
a. Some discussions become the target of trolling and it's necessary to lock threads, unfortunately it happens sometimes. If somebody has made a rude comment then you may want to report that as a code of conduct violation. The developers are volunteers and don't have infinite time to handle all the work that's thrown at them. The disagreement with Pop!_OS was disappointing but I don't know who else you can blame for that, if Pop!_OS wants to go their own way then that is completely their decision. They aren't forced to contribute upstream and I'd say that's good for them and their goals.
b. There isn't really any funding to pay to fix those issues. They're being fixed by volunteers, so progress is slow.
c. I have no idea what this means, extensions are still there.
d. There are issues with Flatpak but all the other options are worse and are more unstable. Before Flatpak, there was just no way for upstream developers to make an "official" packaging for apps. The theming interfaces haven't really changed because those didn't really exist, those were a hack for the entirety of GNOME 3. Having one person implement a design and then gather feedback on it from the community is how open source works. If the community wants it then they'll use it, if they don't then they'll use something else. I'm confused how else you'd expect it to go. Talk is cheap, putting working prototypes in front of the community and then gathering feedback from there is what gets things done.
I also don't really understand why you're saying this makes them the bad guys or comes at the expense of the rest of the community. Like, none of this affects KDE. KDE has their own middleware libraries and makes their own changes. They don't depend on any GNOME libraries. Even XFCE that depends on some libraries like GTK doesn't really have to deal with any of this. GNOME's issues with extensions don't affect them at all because they don't use the GNOME shell, they can package their apps with whatever they want and they don't have to use Flatpak, they probably won't use libadwaita or if they do they'll heavily modify it, etc.
b. There isn't really any funding to pay to fix those issues. They're being fixed by volunteers, so progress is slow.
c. I have no idea what this means, extensions are still there.
d. There are issues with Flatpak but all the other options are worse and are more unstable. Before Flatpak, there was just no way for upstream developers to make an "official" packaging for apps. The theming interfaces haven't really changed because those didn't really exist, those were a hack for the entirety of GNOME 3. Having one person implement a design and then gather feedback on it from the community is how open source works. If the community wants it then they'll use it, if they don't then they'll use something else. I'm confused how else you'd expect it to go. Talk is cheap, putting working prototypes in front of the community and then gathering feedback from there is what gets things done.
I also don't really understand why you're saying this makes them the bad guys or comes at the expense of the rest of the community. Like, none of this affects KDE. KDE has their own middleware libraries and makes their own changes. They don't depend on any GNOME libraries. Even XFCE that depends on some libraries like GTK doesn't really have to deal with any of this. GNOME's issues with extensions don't affect them at all because they don't use the GNOME shell, they can package their apps with whatever they want and they don't have to use Flatpak, they probably won't use libadwaita or if they do they'll heavily modify it, etc.
>Just because you disagree with them, it doesn't make them the "bad guys".
I was replying on the consistency topic. some projects offer the user a consistent experience by offering both Qt/GTK support and others don't care and would rather force their branding on you.
I was replying on the consistency topic. some projects offer the user a consistent experience by offering both Qt/GTK support and others don't care and would rather force their branding on you.
They may not be bad people, but their GUI framework is pretty bad.
As much as I think that GNOME is a joke at this point (and has been for well over a decade), is that really such a bad thing that they focus on supporting their graphical toolkit of choice?
Besides, the real solution here is for developers to switch to QT and stop using GTK. ;)
Besides, the real solution here is for developers to switch to QT and stop using GTK. ;)
Qt, unfortunately, by nature of being C++, is much harder to link into a different language. GTK is a plain C API. So, if you’re using plain C, Rust, C#, etc, it’s a heck of a lot easier to use GTK than Qt.
The thing is that GNOME project and GNOME based distros should put just a bit of effort to support Qt programs, like have the same File Picker Dialog or even have GTK2 and GTK3 use the same fucking File Picker or at least with the same fucking File Sorting.
About easy of use I am sure that you are more productive with a professional toolkit like Qt and a mature language like c++ then fucking around with some broken/incomplete/buggy C# or Rust GTK bindings. Though I think you can do simple Python apps with GTK GUIs but for professional applications that are targeting crossplatform trust me Qt is the solution (I never seen a good GUI cross platform pro application , Linus Torvalds himself used Qt for his app because his Red Hat friends could not answer him on how to do some complex GUI in GTK)
About easy of use I am sure that you are more productive with a professional toolkit like Qt and a mature language like c++ then fucking around with some broken/incomplete/buggy C# or Rust GTK bindings. Though I think you can do simple Python apps with GTK GUIs but for professional applications that are targeting crossplatform trust me Qt is the solution (I never seen a good GUI cross platform pro application , Linus Torvalds himself used Qt for his app because his Red Hat friends could not answer him on how to do some complex GUI in GTK)
You get the DE's file chooser if you use xdg-desktop-portal, which has a KDE backend.
This is a recent development and that was designed to support GNOME/RedHat's flatpack , we should not get tricked to believe GNOME would have done this for helping someone else then themselves(do they support this in GTK2 apps too?, I really hate having different file choser with different sorting order of files and folders)
It probably cannot be done automatically in GTK2 apps because of API differences. GTK2 apps could call the portal API manually or put the functionality in another library.
>we should not get tricked to believe GNOME would have done this for helping someone else then themselves
Well they actually did, the flatpak API was designed to support multiple toolkits.
>we should not get tricked to believe GNOME would have done this for helping someone else then themselves
Well they actually did, the flatpak API was designed to support multiple toolkits.
Re consistency: Am I the only that finds all those burgerbuttons and cluttered window frames (I think they may even call them decorations!) anything but?
Give me a title bar and good old many bars please.
Give me a title bar and good old many bars please.
Lutris is great, but the UI is not as polished, and is probably still geared towards more advanced users.
Lutris is focused mostly on games and options that benefit games.
You can run manually any application you want. It just does not offer one-click install for non-games. I believe lutris offers better runner configuration.
I'm confused...Crossover (a commercial product using Wine as its backend and contributes back to the Wine project[1]) uses the term "bottles" for its container-like method to install Windows apps on Linux and macOS. Is this an offshoot or extension of Crossover, or is it a blatant ripoff of their already existing service and name? Codeweavers (the makers of Crossover) have been using the term "bottle" in this paradigm since at least the late 2000s[2].
[1] https://www.codeweavers.com/crossover#linux
[2] https://forums.macrumors.com/threads/crossover-and-bottles.5...
[1] https://www.codeweavers.com/crossover#linux
[2] https://forums.macrumors.com/threads/crossover-and-bottles.5...
The WineHQ official documentation makes reference to WINEPREFIX being termed a 'bottle', and there are quite a few previous open source projects listed with titles stemming from bottles, so I'm not sure that it's a crossover specific term (and if it is, it seems to have been adopted by the open source project too).
And let's be honest, although cute, it's a pretty obvious term for a project called Wine.
And let's be honest, although cute, it's a pretty obvious term for a project called Wine.
“Blatant ripoff” is a bit harsh. “Bottles” isn’t exactly that original or clever when considering the software that undergirds it.
Especially considering that the wine project which Crossover relies in and contributes to also uses the term 'bottles' to encapsulate how they create different Windows environments.
Afaik, this project is reasonably old as well, I remember looking at early versions when I was at the uni around 2010.
Looks like a replacement for ye-olde PlayOnLinux, which if I ever move to Linux Desktop[0] was going to be something I would write my own tooling to replace[1].
It is not clear from looking over the website, but since bottles appear closely related to Flatpak I am wondering if they support being installed to a different path than the default. Flatpak doesn't allow you to do this in a piecemeal way[2], but it does allow you to set up more than one entire Flatpak environment to different paths[3]. I'm hoping bottles can at least manage that?
[0] There are dozens of tools on my list for this, mostly around application and container management.
[1] I am a very vocal critic of the way Linux Desktop does things, but Windows is becoming worse at an alarming rate so it will probably be the least-worst option in a few years.
[2] A regression from features we had in desktop OSs since the 80s.
[3] Not that any GUI frontend for it pays attention to that. sigh
It is not clear from looking over the website, but since bottles appear closely related to Flatpak I am wondering if they support being installed to a different path than the default. Flatpak doesn't allow you to do this in a piecemeal way[2], but it does allow you to set up more than one entire Flatpak environment to different paths[3]. I'm hoping bottles can at least manage that?
[0] There are dozens of tools on my list for this, mostly around application and container management.
[1] I am a very vocal critic of the way Linux Desktop does things, but Windows is becoming worse at an alarming rate so it will probably be the least-worst option in a few years.
[2] A regression from features we had in desktop OSs since the 80s.
[3] Not that any GUI frontend for it pays attention to that. sigh
Idk anything about bottles, but just curious why you would want that feature? Like, what is a compelling use case for it?
You probably know this already, but the point of Flatpak is to offer sandboxing and packaging of all dependencies in an isolated way. Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit. It’s a bad fit for the tech IMO, and unnecessary since AppImage already offers exactly that functionality, but without the sandboxing (and other) features.
You probably know this already, but the point of Flatpak is to offer sandboxing and packaging of all dependencies in an isolated way. Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit. It’s a bad fit for the tech IMO, and unnecessary since AppImage already offers exactly that functionality, but without the sandboxing (and other) features.
> Idk anything about bottles, but just curious why you would want that feature? Like, what is a compelling use case for it?
Being able to run some applications from super fast but small NVMe disk and less important ones from slow but huge spinning rust disk, being able to run applications from a network share, CD, USB stick, etc. Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them.
> Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit.
If Flatpak had considered this ability from the beginning it wouldn't be. Hell it might not be that difficult now, I haven't looked at the source for Flatpak and how it does things behind the scenes is otherwise not documented as far as I can tell. As you mentioned, AppImage implements it without much difficulty, and AppImages can be securely isolated by firejail. Combining the two concepts in the same package shouldn't be that hard. Keep runtimes in "installations" and let applications exists as single-directory self-contained units wherever the user wants them. What is fundamentally difficult about this?
> unnecessary since AppImage already offers exactly that functionality
If AppImage were fast becoming the new standard in Linux Desktop application distribution we wouldn't be having this conversation.
Being able to run some applications from super fast but small NVMe disk and less important ones from slow but huge spinning rust disk, being able to run applications from a network share, CD, USB stick, etc. Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them.
> Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit.
If Flatpak had considered this ability from the beginning it wouldn't be. Hell it might not be that difficult now, I haven't looked at the source for Flatpak and how it does things behind the scenes is otherwise not documented as far as I can tell. As you mentioned, AppImage implements it without much difficulty, and AppImages can be securely isolated by firejail. Combining the two concepts in the same package shouldn't be that hard. Keep runtimes in "installations" and let applications exists as single-directory self-contained units wherever the user wants them. What is fundamentally difficult about this?
> unnecessary since AppImage already offers exactly that functionality
If AppImage were fast becoming the new standard in Linux Desktop application distribution we wouldn't be having this conversation.
> Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them.
Linux desktops can do this. Flatpak maybe can't (Idk, I don't use them that often, but I'd be surprised if they couldn't), but even before AppImage, Flatpak, Snap, etc you could always just run an application from wherever you want. You could do that 20 years ago, and you can do it today.
Desktops in the 80s didn't have sandboxing, but modern Linux desktops do. You can either implement sandboxing yourself through syscalls, use something like Systemd, or use the significantly more user friendly Flatpaks.
...Or don't use sandboxing at all, and do whatever you want. Download a (hopefully statically-linked) ELF from the internet, chmod +x it, then execute.
> standard in Linux Desktop application distribution
There is no such thing. There never has been, and there never will be :P
Linux desktops can do this. Flatpak maybe can't (Idk, I don't use them that often, but I'd be surprised if they couldn't), but even before AppImage, Flatpak, Snap, etc you could always just run an application from wherever you want. You could do that 20 years ago, and you can do it today.
Desktops in the 80s didn't have sandboxing, but modern Linux desktops do. You can either implement sandboxing yourself through syscalls, use something like Systemd, or use the significantly more user friendly Flatpaks.
...Or don't use sandboxing at all, and do whatever you want. Download a (hopefully statically-linked) ELF from the internet, chmod +x it, then execute.
> standard in Linux Desktop application distribution
There is no such thing. There never has been, and there never will be :P
> Being able to run some applications from super fast but small NVMe disk and less important ones from slow but huge spinning rust disk
1TB NVME drives aren't very expensive on the order of $80-$100 US. This is already big enough for your entire OS even with several very large games installed. The natural split if you have multiple drives would be between OS and backups/multimedia.
I see this immediately being used for pirated software and games. It could also be used to implement a cross platform app store like interface to install legitimate software. It could even be integrated with the same store interface as one uses to install traditional packages and flatpaks for a true one stop shop.
1TB NVME drives aren't very expensive on the order of $80-$100 US. This is already big enough for your entire OS even with several very large games installed. The natural split if you have multiple drives would be between OS and backups/multimedia.
I see this immediately being used for pirated software and games. It could also be used to implement a cross platform app store like interface to install legitimate software. It could even be integrated with the same store interface as one uses to install traditional packages and flatpaks for a true one stop shop.
> 1TB NVME drives aren't very expensive on the order of $80-$100 US.
That isn't the point. I have in my possession several small form factor computers that have 16GB disks in them. "just spend $80-100 each on them" is not a good excuse for having such an inflexible system that it demands everything be on one disk.
The original Mac did this on floppies in 1984. It is 2021, our software should be able to do better.
That isn't the point. I have in my possession several small form factor computers that have 16GB disks in them. "just spend $80-100 each on them" is not a good excuse for having such an inflexible system that it demands everything be on one disk.
The original Mac did this on floppies in 1984. It is 2021, our software should be able to do better.
You have several toys. The purpose of software isn't to optimize for an interesting use case you have devised for your toys it's for actual machines to provide useful work and engaging play. Faster file access for limited files is accomplished by
- caching in ram
- on disk cache
- an explicit read cache device
All of these are broadly applicable and effective to the other 99.9% of actual devices.
- caching in ram
- on disk cache
- an explicit read cache device
All of these are broadly applicable and effective to the other 99.9% of actual devices.
[deleted]
Right...I get where you're coming from but I think where you're coming from is indicative of the why things changed.
It's neat old Mac's from the 80s could to do that...but they had to be able to do that in order to be useful. In other words, it wasn't a "cool feature", it was something they had to be able to do.
I imagine that when storage became more plentiful OS developers became less interested in implementing solutions to problems of this nature and who can blame them really. Supporting a use-case that almost no one cares about anymore is rather unrewarding.
As others have mentioned, there are plenty of ways to achieve this on Linux today, they just seem to involve more fiddling than you'd like. That, unfortunately, is the nature of the beast.
Linux is a tinkerers OS (that just happened to become popular for servers) and expecting it to change its stripes is asking a lot :-)
It's neat old Mac's from the 80s could to do that...but they had to be able to do that in order to be useful. In other words, it wasn't a "cool feature", it was something they had to be able to do.
I imagine that when storage became more plentiful OS developers became less interested in implementing solutions to problems of this nature and who can blame them really. Supporting a use-case that almost no one cares about anymore is rather unrewarding.
As others have mentioned, there are plenty of ways to achieve this on Linux today, they just seem to involve more fiddling than you'd like. That, unfortunately, is the nature of the beast.
Linux is a tinkerers OS (that just happened to become popular for servers) and expecting it to change its stripes is asking a lot :-)
> I imagine that when storage became more plentiful OS developers became less interested in implementing solutions to problems of this nature and who can blame them really.
You say this like making an application this way is some difficult problem. The whole point of me pointing out that it was the way applications worked on a Mac in 1984 (or indeed any of a dozen other desktop OSs) is that it isn't actually difficult at all. The difficulty it appears to have on Linux is all artificially induced by the culture of Linux software development.
> Linux is a tinkerers OS (that just happened to become popular for servers) and expecting it to change its stripes is asking a lot :-)
I don't expect it to change. I've been hoping Linux people would see the light for 20 years and it hasn't changed. That doesn't mean I have to like it or pretend that it's a good idea.
You say this like making an application this way is some difficult problem. The whole point of me pointing out that it was the way applications worked on a Mac in 1984 (or indeed any of a dozen other desktop OSs) is that it isn't actually difficult at all. The difficulty it appears to have on Linux is all artificially induced by the culture of Linux software development.
> Linux is a tinkerers OS (that just happened to become popular for servers) and expecting it to change its stripes is asking a lot :-)
I don't expect it to change. I've been hoping Linux people would see the light for 20 years and it hasn't changed. That doesn't mean I have to like it or pretend that it's a good idea.
> [0] There are dozens of tools on my list for this, mostly around application and container management.
Could you share that list? I've had precisely the opposite problem with container management - whenever I have to use Windows, I find container management so unwieldy. And what do you mean by "application management"?
Could you share that list? I've had precisely the opposite problem with container management - whenever I have to use Windows, I find container management so unwieldy. And what do you mean by "application management"?
> if they support being installed to a different path than the default.
There is an AppImage version if you want that. Also have snap, .deb, AUR, and dnf install options, from what I saw on their Installation page.
It used to be AppImage that they push until after some discussion makes them push Flatpak version more.
There is an AppImage version if you want that. Also have snap, .deb, AUR, and dnf install options, from what I saw on their Installation page.
It used to be AppImage that they push until after some discussion makes them push Flatpak version more.
It's a shame winepak never really took off https://www.winepak.org/
To make this clear, there hasn't been much activity since 2018: https://github.com/winepak/winepak
To make this clear, there hasn't been much activity since 2018: https://github.com/winepak/winepak
That's fantastic! I've been trying to package as many apps as I can as flatpak (because flatpak rocks, fight me), I will definitely look into winepak to package Windows-only software. The fact that it uses a standard and common-place technology, it just needs more exposure IMO. This is the first time I have heard of it.
EDIT: nevermind...
EDIT: nevermind...
$ flatpak remote-add --if-not-exists winepak https://dl.winepak.org/repo/winepak.flatpakrepo
error: Signature made Fri 20 Jul 2018 03:30:34 BST using RSA key ID A959831C080B608F
BAD signature from " <[email protected]>"
Key expired Tue 09 Jun 2020 19:16:34 BSTIt's not active anymore.
Which is a real shame. I can definitely see some value in winepak, and flatpaks could be built from Lutris install scripts, etc.
I don't have much interest in windows apps, but I wouldn't mind donating a bit of money (as opposed to free time) to the project.
Edit: https://github.com/winepak/winepak/issues/23#issuecomment-64...
> The biggest issue with winepak, which is why I haven't been working on it, is that it all revolves around me building things instead of a remote server doing it and having people contribute. I really just need to get the buildbot & sdk in a place that it can auto build an push out. Then it can do all the signing and building again and this shouldn't happen. I just need to find the time.
Maybe a few PR around automation, and/or donated CI runtime could help a whole lot?
I don't have much interest in windows apps, but I wouldn't mind donating a bit of money (as opposed to free time) to the project.
Edit: https://github.com/winepak/winepak/issues/23#issuecomment-64...
> The biggest issue with winepak, which is why I haven't been working on it, is that it all revolves around me building things instead of a remote server doing it and having people contribute. I really just need to get the buildbot & sdk in a place that it can auto build an push out. Then it can do all the signing and building again and this shouldn't happen. I just need to find the time.
Maybe a few PR around automation, and/or donated CI runtime could help a whole lot?
I mean, I can see why. At this point, Flatpak has more open issues than Wine itself...
The flatpak hate gang strikes again. Seriously, more bugs than Wine? For the first time we have a cross-distro packaging system, and I still hear people complaining that the olden days were better. Are you kidding me?
Honestly, I don't even care to entertain this discussion, as for the FIRST TIME in Linux history there is people packaging an application and it works exactly the same everywhere, and some can only meet this achievement by unpaid volunteers with _snark_ because it's not "perfect".
It's tiring to see any effort to make the Linux desktop a reality met with unconstructive opposition from daily Linux desktop users.
/rant
Honestly, I don't even care to entertain this discussion, as for the FIRST TIME in Linux history there is people packaging an application and it works exactly the same everywhere, and some can only meet this achievement by unpaid volunteers with _snark_ because it's not "perfect".
It's tiring to see any effort to make the Linux desktop a reality met with unconstructive opposition from daily Linux desktop users.
/rant
no-one here said the olden days were better. it is possible for something to be generally in the right direction, but still in great need of improvements. dismissing anything not as positive as you'd like as unconstructive is itself unconstructive.
Ah, because saying that flatpak has more issues than Wine _is_ constructive. It is not even close to being true. Yes, I flew off the handle a bit there, but I'm quite done with the useless snark from some commenters, especially since it's pretty common on this forum regarding certain technologies, and in my eyes, completely unwarranted.
Nowhere in my comment I said Flatpak is perfect and doesn't need more work to be really good, and I certainly didn't resort to hyperbole to discredit the work of other people, that's for sure.
I should probably take a walk and not angrily comment on the Internet, I agree...
Nowhere in my comment I said Flatpak is perfect and doesn't need more work to be really good, and I certainly didn't resort to hyperbole to discredit the work of other people, that's for sure.
I should probably take a walk and not angrily comment on the Internet, I agree...
Flatpak is only exciting Redhat who wants to easily provide up to date software on a very old stable base and to be the Google of linux software distribution and to prospective developers who don't at present already have a method of getting debs and rpms to end users easily. This is a small group.
For end users its meant slower startup, apps that ignore user themes, concern that a rogue developer will poison the well with outright malware, concern that a legit developer will get hacked and instantly disseminate malware to all users with their flatpak installed, flatpak only bugs, permissions issues, and additional complexity in managing software.
For developers who already have their software widely available via traditional packaging its something else they have to do in addition to traditional packaging not an alternative because its not universal. In fact last year only a single digit percentage said they used it.
If your prospective users aren't excited about your product perhaps one needs to reconsider if its the users fault for not being excited.
For end users its meant slower startup, apps that ignore user themes, concern that a rogue developer will poison the well with outright malware, concern that a legit developer will get hacked and instantly disseminate malware to all users with their flatpak installed, flatpak only bugs, permissions issues, and additional complexity in managing software.
For developers who already have their software widely available via traditional packaging its something else they have to do in addition to traditional packaging not an alternative because its not universal. In fact last year only a single digit percentage said they used it.
If your prospective users aren't excited about your product perhaps one needs to reconsider if its the users fault for not being excited.
I am excited about flatpak for multiple reasons, which boils down to sandboxing:
1. Proprietary software: most proprietary software authors do not play well with packagers. Moreover, I want any proprietary software properly sandboxed
2. Software that you need sandboxed for various reasons: I've been running flatpak nightlies of stuff I otherwise have installed on my system
3. Installing a program without installing a whole bunch of dependencies, hard to clean up after
4. Cleaning up my home directory
Sandboxing (I know most flathub packages have leaky sandboxes, but that's a start) limits the effect of compromising one flatpak. To be clear: I treat any piece of proprietary software as a possible RCE by the author.
User themes issues are probably fixable.
Slower startup as well, to an extent.
Unfortunately, developers are pretty bad at packaging generally, and don't have distro maintainers watching over their CVEs and upgrading dependencies with the flatpak model... Although users could still dig in and fix these by themselves, and sandboxing still gives a few protections.
1. Proprietary software: most proprietary software authors do not play well with packagers. Moreover, I want any proprietary software properly sandboxed
2. Software that you need sandboxed for various reasons: I've been running flatpak nightlies of stuff I otherwise have installed on my system
3. Installing a program without installing a whole bunch of dependencies, hard to clean up after
4. Cleaning up my home directory
Sandboxing (I know most flathub packages have leaky sandboxes, but that's a start) limits the effect of compromising one flatpak. To be clear: I treat any piece of proprietary software as a possible RCE by the author.
User themes issues are probably fixable.
Slower startup as well, to an extent.
Unfortunately, developers are pretty bad at packaging generally, and don't have distro maintainers watching over their CVEs and upgrading dependencies with the flatpak model... Although users could still dig in and fix these by themselves, and sandboxing still gives a few protections.
The protection offered by sandboxing is like using a garbage bag as a bulletproof vest.
You will have to elaborate instead of throwing easy accusations like these. Linux namespaces are pretty tight, and I make sure that flatpaks that need sandboxing have the right sandboxing mechanisms in place.
In order:
1. Filesystem access is one of the most critical pieces (to me). Flatpaks on flathub often restricts this by default, except for a few packages. Portal mechanisms offer on-demand access to external files and folders.
2. X11 access: I use wayland, and make sure the program I'm launching does too. There is a X11-fallback scheme that blocks access to X11 if wayland is being used.
3. Network access: I usually leave it enabled when needed, there is not much to exfiltrate if filesystem isn't accessible, and that's the main threat I'm concerned about.
I am not very concerned with Pulseaudio, pipewire socket or access to select D-Bus paths.
Sure, it is not an air-gapped computer, nor a virtual machine. The attack surface is bigger, but not that much.
In order:
1. Filesystem access is one of the most critical pieces (to me). Flatpaks on flathub often restricts this by default, except for a few packages. Portal mechanisms offer on-demand access to external files and folders.
2. X11 access: I use wayland, and make sure the program I'm launching does too. There is a X11-fallback scheme that blocks access to X11 if wayland is being used.
3. Network access: I usually leave it enabled when needed, there is not much to exfiltrate if filesystem isn't accessible, and that's the main threat I'm concerned about.
I am not very concerned with Pulseaudio, pipewire socket or access to select D-Bus paths.
Sure, it is not an air-gapped computer, nor a virtual machine. The attack surface is bigger, but not that much.
I'm going to go ahead and presume that anyone intending to release a malicious app or compromised update to a non-malicious application has access to a similarly configured system.
They are thereby incentivized to attack via a method that is successful on their test systems. In particular applications set their own initial permissions (can they also update themselves and acquire greater permissions without user input?) and often contain old outdated and potentially insecure known insecure versions of software already patched or updated in distro repos.
If you put up $1000 and offered to install any malicious app on a current fedora gnome default install VM and see if someone could pwn it your money would be gone in a few hours. You could do this once a month between now and 2025 and I would be surprised if you were ever able to retain your money.
They are thereby incentivized to attack via a method that is successful on their test systems. In particular applications set their own initial permissions (can they also update themselves and acquire greater permissions without user input?) and often contain old outdated and potentially insecure known insecure versions of software already patched or updated in distro repos.
If you put up $1000 and offered to install any malicious app on a current fedora gnome default install VM and see if someone could pwn it your money would be gone in a few hours. You could do this once a month between now and 2025 and I would be surprised if you were ever able to retain your money.
[deleted]
[deleted]
How does this compare to Wine ?
I don't know why you're getting down-voted, it's a legitimate question since the main page doesn't mention wine once.
It is a Wine frontend though, seems to also integrate wine-tricks for dependencies, DXVK and other things from the wine eco-system.
Bottles are isolated Wine environments, similar to containers or VMs. This allows you to install components (e.g. msxml3) to, and modify the configuration of that environment to make the program work without having it affect other applications.
Isolated wine environments are called wineprefixes in wine terms and do not require any additional software.
I think bottles allow you to run a different version of wine inside each bottle (in addition to offering a noob-friendly GUI interface).
Sure, wine supports prefixes, but:
- No filesystem sandbox.
- No handling of dependencies.
- No first-party UI for managing multiple prefixes.
- No filesystem sandbox.
- No handling of dependencies.
- No first-party UI for managing multiple prefixes.
> - No filesystem sandbox.
Every WINEPREFIX defines its own Windows disk drives, so the filesystem is effectively sandboxed. Conventionally, there's (often? always?) a Z:\ drive which points to / on the Linux filesystem, but there doesn't have to be. You can add or remove drive mappings without any additional tools beyond WINE itself, and applications running under WINE can't see files that don't have drives mapped to them, afaik.
Your other two points are correct, though.
Every WINEPREFIX defines its own Windows disk drives, so the filesystem is effectively sandboxed. Conventionally, there's (often? always?) a Z:\ drive which points to / on the Linux filesystem, but there doesn't have to be. You can add or remove drive mappings without any additional tools beyond WINE itself, and applications running under WINE can't see files that don't have drives mapped to them, afaik.
Your other two points are correct, though.
>Every WINEPREFIX defines its own Windows disk drives, so the filesystem is effectively sandboxed.
No, it is definitely not effectively sandboxed. You only need to access / instead of Z:. Wine has no sandbox mechanisms built in. It is also a fairly large codebase which definitely has a bug or two that could be exploited to get around such mechanisms if they existed.
To effectively sandbox, you need the kernel's help. Linux offers namespaces and control groups.
The way you use these comfortably behind a layer of abstraction is through containers. Bottles uses flatpak for the purpose.
No, it is definitely not effectively sandboxed. You only need to access / instead of Z:. Wine has no sandbox mechanisms built in. It is also a fairly large codebase which definitely has a bug or two that could be exploited to get around such mechanisms if they existed.
To effectively sandbox, you need the kernel's help. Linux offers namespaces and control groups.
The way you use these comfortably behind a layer of abstraction is through containers. Bottles uses flatpak for the purpose.
> No, it is definitely not effectively sandboxed. You only need to access / instead of Z:. Wine has no sandbox mechanisms built in. It is also a fairly large codebase which definitely has a bug or two that could be exploited to get around such mechanisms if they existed.
If you don't have Z:\ enabled, how do you actually access those Unix-like paths? When I launch a WINE command prompt in a prefix with no Z:\ enabled, I get:
> To effectively sandbox, you need the kernel's help. Linux offers namespaces and control groups.
> The way you use these comfortably behind a layer of abstraction is through containers. Bottles uses flatpak for the purpose.
This is an improvement for sure, but I've never, ever had some WINE program run amok on my hard disk outside of the drives letters defined for it in the WINE configuration.
Thanks for pointing out the more thoroughgoing sandboxing that Bottles uses beyond just the WINE drive mapping, though.
If you don't have Z:\ enabled, how do you actually access those Unix-like paths? When I launch a WINE command prompt in a prefix with no Z:\ enabled, I get:
wine: could not open working directory L"unix\\home\\pxc\\", starting in the Windows directory.
Microsoft Windows 6.1.7601
unix\home\pxc>dir
Syntax error
unix\home\pxc>cd ..
unix\home>dir
Syntax error
> To effectively sandbox, you need the kernel's help. Linux offers namespaces and control groups.
> The way you use these comfortably behind a layer of abstraction is through containers. Bottles uses flatpak for the purpose.
This is an improvement for sure, but I've never, ever had some WINE program run amok on my hard disk outside of the drives letters defined for it in the WINE configuration.
Thanks for pointing out the more thoroughgoing sandboxing that Bottles uses beyond just the WINE drive mapping, though.
export WINEPREFIX=$HOME/tmp
mkdir $HOME/tmp
wine foo/bar/bla/install.exe> mkdir $HOME/tmp
WINE will automatically create the WINEPREFIX directory for you if it doesn't exist, so it's even simpler than that :)
The real value of bottles (or crossties, or PlayOnLinux definitions, or whatever) in in encoding all the tips and tricks required to get some piece of software running under WINE in a form that lends itself to easy distribution and automation.
WINE will automatically create the WINEPREFIX directory for you if it doesn't exist, so it's even simpler than that :)
The real value of bottles (or crossties, or PlayOnLinux definitions, or whatever) in in encoding all the tips and tricks required to get some piece of software running under WINE in a form that lends itself to easy distribution and automation.
Judging from the Github project page, it uses Wine itself, so is probably just a GUI frontend to it.
I think this uses Wine (it mentions DXVK, which IIRC is for Wine), but handles setting it up correctly for every program you want to use.
I mean, what the hell? This is from India:
"The website has been blocked as per order of Ministry of Electronics and Information Technology under IT Act, 2000."
Why has the Indian govt blocked this website?
"The website has been blocked as per order of Ministry of Electronics and Information Technology under IT Act, 2000."
Why has the Indian govt blocked this website?
Is it still blocked for you? I'm on ACT broadband and the site is available to me, but i think Jio is generally more restrictive.
(For anyone reading from outside India, yes, the government blocks a lot of websites, different internet providers seem to implement different lists, and nobody afaik knows what the actual official list is - or maybe there isn't one, just general instructions from the government about what sort of websites to block, hence the variance.)
(For anyone reading from outside India, yes, the government blocks a lot of websites, different internet providers seem to implement different lists, and nobody afaik knows what the actual official list is - or maybe there isn't one, just general instructions from the government about what sort of websites to block, hence the variance.)
Surprisingly it is not blocked now. What changed within half an hour? Very inexplicable. I'm on BSNL landline broadband, fwiw.
(not Indian)
Maybe the way they implement it is if the domain is first visited by their user, it is put in a queue to review if it's compliant?
Maybe the way they implement it is if the domain is first visited by their user, it is put in a queue to review if it's compliant?
I'm curious, how does this work? It's a HTTPS site, so it's basically a MITM attack, which is not technically possible, is that right? Are you required to install some certification from gov?
Maybe they block entire domains, not individual pages?
That wouldn't be affected by HTTPS at all.
That wouldn't be affected by HTTPS at all.
Depends on the ISP, but some have even done deep packet inspection - https://iamkush.me/sni-airtel/
But if SNI based blocking is the case, it should give ERR_CONNECTION_RESET, here the page appeared with apparently a (cloudflare issued) Valid SSL Certificate with the given text. Isn't that supposed to not happen?
This is what curling the output gave me earlier: https://pastebin.com/Ae5DMn04 , Now the site has mysteriously started working.
This should only be possible if the request is being intercepted somewhere between Cloudflare's server (which might have a unicast location in India) and the actual server that might be happening over HTTP, which is a serious issue! This would also explain why it works sometimes and fails the other times. But that won't explain why it shows my ISP in the blocked message.
To further support this theory, Wireshark showed nothing weird in the TLS exchange, So it either suggests my ISP has cracked encryption (unlikely) or the link between cloudflare middleboxes and the "Internet" should be treated as insecure.
This is what curling the output gave me earlier: https://pastebin.com/Ae5DMn04 , Now the site has mysteriously started working.
This should only be possible if the request is being intercepted somewhere between Cloudflare's server (which might have a unicast location in India) and the actual server that might be happening over HTTP, which is a serious issue! This would also explain why it works sometimes and fails the other times. But that won't explain why it shows my ISP in the blocked message.
To further support this theory, Wireshark showed nothing weird in the TLS exchange, So it either suggests my ISP has cracked encryption (unlikely) or the link between cloudflare middleboxes and the "Internet" should be treated as insecure.
[deleted]
The initial TLS handshake contains the hostname in plaintext, also DNS queries can be sniffed.
On the other hand, MITM would be like changing a certificate in an attempt to alter traffic, this case is simple traffic blocking by doing packet inspection. (Which is also not nice obviously)
Same here on Airtel, India - blocked.
working fine on YouBroadband..
Wow, the first impression is really great.
Finally, a Wine frontend that feels polished and easy to use for beginners. Heck, the documentation alone is worth the project.
I love PlayOnLinux but their decision to go the Java route was a mistake and the rewrite seems to take ages.
Finally, a Wine frontend that feels polished and easy to use for beginners. Heck, the documentation alone is worth the project.
I love PlayOnLinux but their decision to go the Java route was a mistake and the rewrite seems to take ages.
Apparently we've standardized on Windows apps as the standard binary format for games and other software, irrespective of the underlying OS kernel.
Amusingly we're getting to a point where it's easier in many cases to just target Windows than ship native binaries for Linux.
So then the question arrives: since there's going to be a native Windows binary regardless what's the point of putting in the extra effort if it works well enough?
I think compatibility layers (Wine/Proton) are very useful especially considering many developers don't want to put the effort into making a well supported Linux binary (or make something open source so it can be compiled/patched against updated system libraries), but it very well may be a snake eating its own tail situation that hampers further adoption if things are "good enough".
So then the question arrives: since there's going to be a native Windows binary regardless what's the point of putting in the extra effort if it works well enough?
I think compatibility layers (Wine/Proton) are very useful especially considering many developers don't want to put the effort into making a well supported Linux binary (or make something open source so it can be compiled/patched against updated system libraries), but it very well may be a snake eating its own tail situation that hampers further adoption if things are "good enough".
.. Does this make Windows on Linux the "Java" of consistent, universal binaries?
Java has fewer issues with the JVM than Windows games do with Windows
Is this surprising? It has been the default format for 25 years, and a lot of experience and tooling has been developed to support it. It would be very hard for a competitor to overtake that head start advantage.
So is this a Libc issue? Or other standard libraries?
Can we not just try to have a fixed set of interfaces for these libraries or am I insane to think that they don't need to change really any more? (In 99% of cases?)
It feels like everyone doing their own thing in these areas is just making everything totally painful for application authors and so people are coming up with insane bundler systems that just hide the real problem.
Can we not just try to have a fixed set of interfaces for these libraries or am I insane to think that they don't need to change really any more? (In 99% of cases?)
It feels like everyone doing their own thing in these areas is just making everything totally painful for application authors and so people are coming up with insane bundler systems that just hide the real problem.
I feel like if you could take an application compiled for Ubuntu 4.10 and run it on Ubuntu 21.10 without recompiling it or putting it in a VM then maybe this probably wouldn't be the case. Sadly we don't live in that world.
Yet Windows has Linux subsystem and Android emulation. Games sure, but all these OSes are just good at running VMs now.
I want to make sure I understand what this is.
Does this set up and manage multiple isolated Wine & Proton environments?
Does this set up and manage multiple isolated Wine & Proton environments?
As far as I understand, yes[1]! I'll quote
> There are two types of runners in Bottles:
> 1. Wine
> 2. Proton
> The Wine runner is used for all Environments and is therefore in all bottles created, but also for external prefixes imported into Bottles. We support 3 different runners:
[1] https://docs.usebottles.com/components/runners
> There are two types of runners in Bottles:
> 1. Wine
> 2. Proton
> The Wine runner is used for all Environments and is therefore in all bottles created, but also for external prefixes imported into Bottles. We support 3 different runners:
[1] https://docs.usebottles.com/components/runners
I haven't used this software, but FWIW i almost never have to create isolated Wine (well, Wine-staging) environments. I've installed pretty much everything - applications, games, etc - on the default wine prefix and things tend to work just fine. Though i do have installed DXVK and VKD3D-Proton as well as the windows media framework files for games to work properly, but i do not see these as anything different to what i was doing on Windows anyway - including using DXVK to run some D3D9 games that were otherwise broken.
I think in general Wine and Wine-staging are good enough nowadays to not need game-specific hacks that affect the entire wine prefix anymore.
I think in general Wine and Wine-staging are good enough nowadays to not need game-specific hacks that affect the entire wine prefix anymore.
+1 for Bottles. Have been using it for a while. Its excellent. It also has an inbuilt task manager, command line access, and so on for a container/bottle.
> It also has an inbuilt task manager
This is part of WINE. You can access it via
This is part of WINE, too. You can access it with
Bottles definitely seems better than dealing with this manually, to be clear. But those two features are part of WINE itself! :)
This is part of WINE. You can access it via
wine taskmgr
WINEPREFIX=/path/to/prefix wine taskmgr
This is part of WINE, too. You can access it with
wine cmd
konsole -e 'wine cmd'
xterm -e 'wine cmd'
Bottles definitely seems better than dealing with this manually, to be clear. But those two features are part of WINE itself! :)
This is literally amazing, very similar to playonlinux, but much better looking and intuitive.
Thanks for this, it will make much easier to install linux on friends computers hehe
Thanks for this, it will make much easier to install linux on friends computers hehe
First impression is that the gui is beautifully designed, installation on NixOS was (as always with prepackaged Nix packages) painless.
I'm not sure what I should use it for though since I don't really run any windows applications other than games, and I use QEMU for that, only game that hasn't worked in QEMU is "Halo Infinite".
I'm not sure what I should use it for though since I don't really run any windows applications other than games, and I use QEMU for that, only game that hasn't worked in QEMU is "Halo Infinite".
How's that work? You have a QEMU windows box setup to game on?
Why not use Proton?
Why not use Proton?
Yeah I have a QEMU windows box that I game on.
The reason I don't use proton is because compability isn't 100%, whereas actually running windows gets you to a 100%, if we don't count games with predatory anticheats, but those don't work on proton either (For now).
I'm REALLY superstoked about Intels new HPG GPU's, it's rumored they'll have SR-IOV support, meaning I could partition the GPU to run both Windows and Linux at the same time. (There's support for it in my 11th gen Intel CPU on my work laptop, but the software isn't there yet, so I'm not certain it'll work)
The reason I don't use proton is because compability isn't 100%, whereas actually running windows gets you to a 100%, if we don't count games with predatory anticheats, but those don't work on proton either (For now).
I'm REALLY superstoked about Intels new HPG GPU's, it's rumored they'll have SR-IOV support, meaning I could partition the GPU to run both Windows and Linux at the same time. (There's support for it in my 11th gen Intel CPU on my work laptop, but the software isn't there yet, so I'm not certain it'll work)
That's a strange name, Crossover (the company backing Wine developement) uses Bottles as a name for their Wine prefixes.
Yeah I read the website and thought Bottles for winning Ng windows apps on Linux is already a thing - looks like this is a different company that’s ripped off the name.
Ooh this looks very nice. I love how wine “just works” but it means I’m sometimes just really unaware of what’s going on or how my system is configured.
I admit I sometimes just open winetricks and more or less randomly click on a bunch of things to see if it will fix issues when I have them… this might help me out with that
I admit I sometimes just open winetricks and more or less randomly click on a bunch of things to see if it will fix issues when I have them… this might help me out with that
As a developer within this space I am excited for the format for application installers since the alternatives are all terrible
I've tried this on PopOS and unfortunately it was really unstable and couldn't start applications.
But otherwise I think the interface is already better and simpler than some other GUI frontends for wine.
this could be a completely different issue to yours, but i ran into a problem with some software where i selected the .exe installer to run but it wouldn't work as bottles didn't have access to the other installer files in the same folder.
when i moved the installer files inside the bottle it worked no problem. alternatively, flatseal will let you set up permissions for bottles so that it can access your home folder
when i moved the installer files inside the bottle it worked no problem. alternatively, flatseal will let you set up permissions for bottles so that it can access your home folder
This looks cool. Does it make use of the tech Valve has been developing for gaming in Linux?
It (optionally) uses a fork of Proton, the Valve-developed compatability layer. All containers use Wine, but Proton and Lutris are more complex and support more modern titles
Yes, you can choose which Wine environment to run on, by default it's a vanilla Wine environment, or you can pick which Proton version you prefer.
It was not immediately obvious to me - can I also restrict network access?
If you're diehard enough, you can restrict network access yourself with Linux's various native tools for that
I can't find a list of tested working (or to what degree) software - does enough work well that I'm supposed to assume everything does?
I would love to have Fusion 360 working on Linux.
I would love to have Fusion 360 working on Linux.
This is just a frontend to Wine. Most stuff tends to work unless it's doing strange things and has unusual dependencies. Some resources:
https://appdb.winehq.org/objectManager.php?sClass=applicatio...
https://www.protondb.com
https://appdb.winehq.org/objectManager.php?sClass=applicatio...
https://www.protondb.com
I was going to point to the WineHQ AppDB also but the person most active in updating the Fusion360 entry seems to be working on this. https://github.com/cryinkfly/Autodesk-Fusion-360-for-Linux It looks like it's been fairly active over the past year so it's probably what I would start with to get Fusion running.
Kinda rediculous that they tell people to install Flatpak for "the best experience" when their docs say things like:
"After multiple requests, it is now possible to generate the desktop entry for a program directly from Bottles.
...
this feature is not coming for Flatpak users, due to lack of permissions. So if you’re using Flatpak, please don’t worry about this feature, we still have other plans for you."
Sounds like Flatpak isn't the best experience then, is it?
"After multiple requests, it is now possible to generate the desktop entry for a program directly from Bottles.
...
this feature is not coming for Flatpak users, due to lack of permissions. So if you’re using Flatpak, please don’t worry about this feature, we still have other plans for you."
Sounds like Flatpak isn't the best experience then, is it?
I thought this looked nice, so I tried it.
It created a runner, so far so good.
Then I tried to install an app, launched .exe installer
My PC froze, I couldn't even move my mouse, so I had to hard reset.
I tried a second time: this time I was able to move my mouse for about 10 seconds while seemingly nothing happened (other parts of the system froze). Then it, too, froze. So, hard reset again and hard pass on the bottles.
After reboot I had to run fsck on my disk, not a great experience
It created a runner, so far so good.
Then I tried to install an app, launched .exe installer
My PC froze, I couldn't even move my mouse, so I had to hard reset.
I tried a second time: this time I was able to move my mouse for about 10 seconds while seemingly nothing happened (other parts of the system froze). Then it, too, froze. So, hard reset again and hard pass on the bottles.
After reboot I had to run fsck on my disk, not a great experience
I hate when a product landing page doesn't answer the biggest question everyone is going to have. How is this different from Wine?
It's a wrapper around Wine
How does this compare to codeweavers crossover which is also a GUI for wine that uses the term 'bottles'?
Why is this better than playonlinux (contains "quirk" solution for lots of productivity software and is also based on fully managed invidiual wine prefices) or lutris or steam w/ proton for games?
i could never under the new phoenicis playonlinux. it is molasses slow, takes a toll on pc, is buggy. eh.
Can this run office 365 on Linux. I don't really care about alternatives, I need Teams, One Drive, PowerBI and Excel or I can't move. Otherwise I have to stick with WSL
WSL2 is probably hard to beat. They've added GPU passthrough, and now have Wayland built-in with wslg. Some buggy stuff remains, systemd support is a bit rough, etc. But they do keep iterating. I do wish they had a full-screen mode where you could use your own window manager, like many Windows X11 servers optionally allow.
But it's good enough now that I rarely find things that don't work. At least for now, it's also a bit of an escape from corporate over-management of desktops. Most companies haven't yet figured out how to overmanage it in the way they do with regular Windows, Linux, and MacOS.
But it's good enough now that I rarely find things that don't work. At least for now, it's also a bit of an escape from corporate over-management of desktops. Most companies haven't yet figured out how to overmanage it in the way they do with regular Windows, Linux, and MacOS.
That's not the reason people use linux
They move to linux to be in control of their OS, to manage their dependencies and to embrace an open platform that scale from embedded to IoT to datacenters
If your goal is to use a proprietary OS that spy on you and is bloated, only to run a linux VM, then you don't understand why cloud native is 100% linux
That's the problem of the people who work at Microsoft have, they became blind and don't understand the real intent of people using linux!
Bloat driven development is certainly not one of them!
They move to linux to be in control of their OS, to manage their dependencies and to embrace an open platform that scale from embedded to IoT to datacenters
If your goal is to use a proprietary OS that spy on you and is bloated, only to run a linux VM, then you don't understand why cloud native is 100% linux
That's the problem of the people who work at Microsoft have, they became blind and don't understand the real intent of people using linux!
Bloat driven development is certainly not one of them!
I agree that set of people is one group of users. I use WSL to write code for work, where I also need Windows for Office and some drawing tools. I imagine I'm not the only one.
I was able to install following instructions available here: https://old.reddit.com/r/linuxmasterrace/comments/hhvx17/off... and here: https://old.reddit.com/r/linuxmasterrace/comments/hhvx17/off... .
I downloaded the installer from a windows machine. After trying to install and run, it still complained about a missing implementation. The tutorial explains how to install using wine 5.11, to make it run correctly, simply run it using wine 5.12 after installed.
I used bottles to install wine versions my distro wasn't shipped with. Also used winetricks to install fonts. At the end it works, but be aware: it is slow and buggy.
I downloaded the installer from a windows machine. After trying to install and run, it still complained about a missing implementation. The tutorial explains how to install using wine 5.11, to make it run correctly, simply run it using wine 5.12 after installed.
I used bottles to install wine versions my distro wasn't shipped with. Also used winetricks to install fonts. At the end it works, but be aware: it is slow and buggy.
is that not the same link twice?
Think you're right. Correct links: https://old.reddit.com/r/linuxmasterrace/comments/hhvx17/off... and https://old.reddit.com/r/linuxmasterrace/comments/hhvx17/off...
No. Wine can't implement modern features fast enough for stuff like office to work.
That's not the goal of this tool, though. It's a quality of life improvement for programs that are already known to work in WINE.
That's not the goal of this tool, though. It's a quality of life improvement for programs that are already known to work in WINE.
For everyone questioning the need for MS office. If you are an advanced Excel user nothing else will do.
Office online?
It's been getting much better over the years, I remember Pivot Tables making it in being the hot shit in the online version a couple years back, but it's still not to parity for advanced use. The biggest pain point probably being limited data sources though I think there is still a file size limit too (30 MB last I remember, better than at first!). New features still get cooked in the desktop previews first as well e.g. even if your account is set to insider preview lamdba won't work in Excel Online at the moment.
It looks like the only officially supported program that isn't a game is amazon music [1]. The main project for running windows on Linux has a partially working distribution of Office 365. My impression is that it sometimes works with significant manual effort, wouldn't be reliable enough to depend on without a backup system [2].
When I need Office apps to communicate with clients I use a combination of Google Docs download as docx, Office Online, and a VM.
[1]: https://github.com/bottlesdevs/programs [2]: https://appdb.winehq.org/objectManager.php?sClass=version&iI...
When I need Office apps to communicate with clients I use a combination of Google Docs download as docx, Office Online, and a VM.
[1]: https://github.com/bottlesdevs/programs [2]: https://appdb.winehq.org/objectManager.php?sClass=version&iI...
Android office apps seem to work for me via waydroid. Otherwise, web office seems to be enough for 90% of people (where libreoffice and onlyoffice already seem to cover the needs for 70%). Of course, you might have a very specific need for MS Office, no judgement :)
edit: though a VM can work too.
edit: though a VM can work too.
I've just tried with Office 2013 and 2016, neither worked. Didn't make it as far as the installer screen each time.
To make sure it was installed properly I tried Notepad++ and it worked flawlessly.
Office is just a bit of a pain.
To make sure it was installed properly I tried Notepad++ and it worked flawlessly.
Office is just a bit of a pain.
I once read that office basically functions like a VM. I don't know how true that was but I guess it makes it not really software but a deployment.
Well stick to windows, nobody forcing you to move!
If linux doesn't have what you need, it's 100% fine!
Linux is here for people willing to stop depending on proprietary mono-platform driven stacks
The world is moving, you'll be left behind, if not already
Developpers already moved with it, what's left are the old "ms" office people! the modern ones use gmail suite
If linux doesn't have what you need, it's 100% fine!
Linux is here for people willing to stop depending on proprietary mono-platform driven stacks
The world is moving, you'll be left behind, if not already
Developpers already moved with it, what's left are the old "ms" office people! the modern ones use gmail suite
Looks terrific. I have actually not needed to use Wine for so long due to the proliferation of web software and cross platform applications but perhaps if I were to play games!
Yes, this would be great for gaming, but I personally play almost all of the games from Steam. I even add shortcuts to native Linux non-steam games to Steam library, so all of them would stay in one place.
I just wanna ask if i download ubisoft connect (gaming service) or epic game launcher, using this app, would it be easily to run? btw, I'm using linux mint.
I wonder if this will work for running Java GUI scientific apps (Gephi, Concept Explorer) that are pretty much impossible to get running correctly on Linux.
You mean, “impossible to get running correctly anywhere”?
(The problem with running Java apps is that they are tied to a range of versions of JRE, like, for instance, version 8 or earlier.)
(The problem with running Java apps is that they are tied to a range of versions of JRE, like, for instance, version 8 or earlier.)
Where's the run-MacOS-apps-on-Linux equivalent?
It's called Darling, apparently it works well for most Terminal apps while support for GUI apps is still limited at the moment
https://www.darlinghq.org/
https://github.com/darlinghq/darling
https://www.darlinghq.org/
https://github.com/darlinghq/darling
What interesting macOS-only terminal apps should I try with Darling?
I haven't tried it so take this with a grain of salt, but it seems that terminal-only apps are supported fairly well. I see from the docs that you can even use Brew from inside Darling.
Yeah, the thing is that I don't know any CLI programs that are exclusive to macOS and might be useful to run on Linux. That's what I was asking about
If you need Windows software, why not just run Windows? Why make life more difficult?
Many people (like myself) are very happy with Linux and have been for years. We have no interest in "auto rebooting for security patches", "treating file locking like it was security" or having "relevant ads" shown to us. However, there might be 1 or 2 Windows apps we wish to run, so things like this are nice. I assure you that my overall experience is not "more difficult" than Windows (the exact opposite in fact).
Windows is kinda crap.
The cost of it not withstanding, the OS itself is just janky. So. I’d prefer not to.
The cost of it not withstanding, the OS itself is just janky. So. I’d prefer not to.
People keep saying that, but the only stable experience I have had is with Windows. Every single Linux distro I have tried (Ubuntu, Debian, Manjaro, Fedora) has been inherenty more sluggish and painful to use than Windows for me (even if you were to ignore the initial setup problems with various hardware).
Windows unactivated is actually free to use (just use a generic key from its official documentation) and most of its preloaded bloatware can be removed with single-use scripts.
Windows unactivated is actually free to use (just use a generic key from its official documentation) and most of its preloaded bloatware can be removed with single-use scripts.
I guess it depends where you are?
It’s so much of a surface area that it’s hard to be objective on all fronts, nothing is perfect and I could come up with 1000 ways that Linux is better or that macos is better or that windows is better. But it largely doesn’t matter.
The parent postulated “why not use windows”. Well, I don’t like using windows but often I need to run software developed for windows.
The same way that windows now has an emulation/virt layer for Linux, people want to use Linux programs from windows.
I dont begrudge those users for using Linux software on windows or look down on them for that.
Enjoying the Experience of the operating system you use is just so incredibly subjective…
I recently had the mispleasure of reinstalling a windows machine and kept getting frustrated at the requirement to have a Microsoft account, drivers that didn’t seem to find my drives (?) but could with an Intel computer from the same brand (and similar model) of motherboard. I got frustrated when trying to use the win32 api because it expects WTF16, padded and null terminated strings but only passed as mutable pointers.
And if you want to pass a strict to a function, you must pass a raw pointer. Which is inherently unsafe in rust.
These things annoy me.
Then: I tried to activate windows and saw the jaw dropping price. The price is more than a quarter of a reasonably priced home PC. No wonder the OEMs install bloatware to get the price down.
It’s so much of a surface area that it’s hard to be objective on all fronts, nothing is perfect and I could come up with 1000 ways that Linux is better or that macos is better or that windows is better. But it largely doesn’t matter.
The parent postulated “why not use windows”. Well, I don’t like using windows but often I need to run software developed for windows.
The same way that windows now has an emulation/virt layer for Linux, people want to use Linux programs from windows.
I dont begrudge those users for using Linux software on windows or look down on them for that.
Enjoying the Experience of the operating system you use is just so incredibly subjective…
I recently had the mispleasure of reinstalling a windows machine and kept getting frustrated at the requirement to have a Microsoft account, drivers that didn’t seem to find my drives (?) but could with an Intel computer from the same brand (and similar model) of motherboard. I got frustrated when trying to use the win32 api because it expects WTF16, padded and null terminated strings but only passed as mutable pointers.
And if you want to pass a strict to a function, you must pass a raw pointer. Which is inherently unsafe in rust.
These things annoy me.
Then: I tried to activate windows and saw the jaw dropping price. The price is more than a quarter of a reasonably priced home PC. No wonder the OEMs install bloatware to get the price down.
Because we need some Windows-only software and some Linux-only software. And the occasional Mac-only (or whatever else) software too. Life is less difficult when it all works in the same window manager and accesses the same filesystem, if that is possible.
not sure if you are trolling or not but i have around 60 programs that i use on linux and 1 program that only supports windows, so having to dual boot just so i could run 1 program would make things a lot more difficult
Windows can run Linux in the subsystem and has a better Android emulator than Linux. Windows doesn’t run old windows programs as well as wine though, and if it hasn’t happened yet I can’t wait for the day you run legacy windows programs in the Linux subsystem through wine.
You’re not wrong, using virtualization like a Windows VM in Linux is still using windows and is the best way for compatibility. Wine either works ok (mostly), needs lots of weird configuration to get it to intergrate into Linux or look ok, or it doesn’t work at all most of the time.
You’re not wrong, using virtualization like a Windows VM in Linux is still using windows and is the best way for compatibility. Wine either works ok (mostly), needs lots of weird configuration to get it to intergrate into Linux or look ok, or it doesn’t work at all most of the time.
[deleted]
Will this enable me to run Office365 and CreativeCloud on Linux?
Can Wine nowadays run CAD software like Inventor, etc?
Has anyone figured out how to run Visio? ;-)
I don't want to have to learn an entirely new vocabulary for every new utility that comes out.
[deleted]
tl;dr: that seems to be a GUI to create&mange separate wine/proton-based wineprefixes and install libs/apps into them using winetricks.
Basically, just another Lutris/PlayOnLinux/whatever else.
Basically, just another Lutris/PlayOnLinux/whatever else.
-- small rant
The UI looks very nice and polished
.. that would be true if it was a mobile app, not a desktop app..
i'm tired of constant scroll/touch/gesture based UX on desktop, it's wrong
-- rant end
Running windows app?
What kind of windows only app does people need nowadays?
I see none personally
Office? meh, gmail/google doc etc replaced it
3D? blender is here
Game Engines? they run on linux
Editors? they run on linux
What's left? i literally see none!
The UI looks very nice and polished
.. that would be true if it was a mobile app, not a desktop app..
i'm tired of constant scroll/touch/gesture based UX on desktop, it's wrong
-- rant end
Running windows app?
What kind of windows only app does people need nowadays?
I see none personally
Office? meh, gmail/google doc etc replaced it
3D? blender is here
Game Engines? they run on linux
Editors? they run on linux
What's left? i literally see none!
mainly reason 11 (DAW, music making software), then also mp3 tag editor, a gpx editor, jpegview, and a few others a can't remember. they all have pretty messed up ui but some of them are still better than any of the linux alternatives ive checked out so far and some i just haven't bothered looking around yet
Curious how this compares to Lutris[1]. I can see it has support for it as a runner, however as far as I can tell it achieves the same thing by maintaining separate wineprefixes.
[1] https://lutris.net/