Bottles: GUI front end to run Windows software on Linux
usebottles.com
usebottles.com
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.
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.
Just because you disagree with them, it doesn't make them the "bad guys".
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.
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.
I fail to see why GNOME, or any DE for that matter, is something that should be recommended by a distribution like NixOS.
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...
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.
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
? 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.
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.
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.
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.
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.
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)
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.
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.
>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.
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.
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 a pragmatist, not an idealist. Promises mean very little, especially coming from the modern GTK team.
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.
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.
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.
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'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-...
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.
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.
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.
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.
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?
>despite the apparent impression most people seem to be under when they use GNOME Tweak Tool
I'm not sure what that impression is, GNOME Tweak Tool has always been this way. Other desktops like XFCE can of course expose the setting and make it supported but that's only guaranteed to work with XFCE apps that they've designed to work with that setting.
I don't have much skin in the game to be honest because I've given up on using any GUI apps on Linux wherever possible. If I do use GUI apps, I keep looking for ways to quit using them too. The attitude exhibited by GTK and GNOME developers on their issue trackers and the unstable nature of KDE apps on Wayland has made me cynical about GUI on Linux.
I wouldn't know how to differentiate between "supported" and "unsupported" features on GNOME. If basic features like changing keyboard shortcuts are "unsupported" on GNOME, I'm not sure who the target audience of such a DE is, except maybe grandmas, managers, and people with attention deficit issues. Then again, I fail to see why such people would bother with using Linux in the first place.
And yeah, I would use KDE apps but they're almost unusable on swaywm on Wayland so I've stopped using them as well.
I'll focus on creating and using only command line tools and TUIs. Unlike the GUI mess that we have, they are mostly platform independent and can be used almost anywhere.
It was nice talking to you. Thanks for your time.
I think you're misinterpreting the attitude, or rather that attitude is the same anywhere. GTK and GNOME developers might just be more honest about it, they're fairly limited in what they can do so they can't really fix every single issue on the tracker in a timely manner. That attitude is the same thing with KDE, they have limited time and so can't stabilize things as fast as they'd like. I'd say use Windows or MacOS if you want an OS that is stable and don't want to deal with the limitations of Linux, it's quite far behind on the desktop, and using things like i3wm or swaywm is putting it even further behind because those don't comprise a complete desktop.
>And yeah, I would use KDE apps but they're almost unusable on swaywm on Wayland so I've stopped using them as well.
The problem there is the same, nothing is really native to swaywm or i3wm so you'll probably find that most apps suffer usability issues on them. That's been my experience with third party window managers. If you like KDE apps you probably should use KDE for the most reliable experience.
>I'll focus on creating and using only command line tools and TUIs. Unlike the GUI mess that we have, they are mostly platform independent and can be used almost anywhere.
TUIs have a number of other issues so I can't really suggest those either, you're forgoing a lot by making them. There are no perfect options for platform independent GUIs, everything is a trade off. I would personally suggest making web apps or Electron apps before I would suggest TUIs.
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 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.
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.
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.
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.
I wish something called user choice and configuration options existed in this reality.
Sucks that end users can't "hard fork" and fix their shit, but I can't fix planes either, we all pay for our choices.
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.
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.
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...
[0] https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
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.
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.
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 )
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)
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.
OK, good news then for old apps and games , is there a solution ready for new applications like Qt,Electron ones that were not created for GNOME? Can you resize them on Wayland or you are forced on X11 ? If you do not use Wayland is he Window Manager still implementing the SSD or they removed the code (I think I read something about code getting removed but I am might be thinking about something else).
So my question if I were to test GNOME+Wayland will this work correct:
1 old games , games that use DOXbox or emulators
2 new games in Wine or native
3 Qt or other apps like Intellij,Thunderbird, Visual Studio Code, VLC, Slack (does GNOME still has no system tray for Slack/email clients ?)
4 is GTK still recommended for cross platform development? isn't cross platform support and GNOME design in a contradiction? any such example of a cross platform GTK4 complex application
I am sorry if my knowledge is a bit outdated, I am no longer reading Linux news ,podcasts or Linux reddits (I got tired about reading all the small drama stuff, the big news will reach me somehow anyway)
2. Wine apps will probably have to draw the win32 decorations. Native apps can implement their own decorations or can use GTK or Qt to draw their decorations.
3. Qt does have its own CSD decorations, VLC should be able to use that. Intellij is a Java app so I'm not sure about that one but Thunderbird should use GTK decorations. The rest are Electron apps and Electron has a PR open for CSD: https://github.com/electron/electron/pull/29618
A system tray can be added to GNOME with an extension.
4. GTK is not a cross platform toolkit like Qt where it tries to draw everything with native widgets, but it is a portable toolkit meaning that you can port applications to other platforms and they will more or less look the same. I don't know anyone using it ship Windows applications, some improvements have been made to get it working better on Windows though: https://www.collabora.com/news-and-blog/blog/2021/03/18/buil...
> GTK is not a cross platform toolkit like Qt where it tries to draw everything with native widgets
Just a correction, Qt does not use native widget, they have code that will adapt and paint the thigns too look and work as native widgets, so for example they have button groups that when you use it say for OK-Cancel buttons it will change it to Cancel-OK on different platforms (some platforms have the order reversed). Also Qt will paint the OK/Cancel button icons on KDE but not on Windows/GNOME . So in fact Qt devs put the effort in and wrote code and themes to get things look native, use the native file dialogs, use the native notifications, system tray, the native paths etc (not ike the other toolkit that doesn't care about integration, theming and configuration)
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.
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.
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.
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.
Besides, the real solution here is for developers to switch to QT and stop using 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)
>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.
Give me a title bar and good old many bars please.
[1] https://www.codeweavers.com/crossover#linux
[2] https://forums.macrumors.com/threads/crossover-and-bottles.5...
And let's be honest, although cute, it's a pretty obvious term for a project called Wine.
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
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.
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.
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
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.
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.
- 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.
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 :-)
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.
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.
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"?
To make this clear, there hasn't been much activity since 2018: https://github.com/winepak/winepak
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 " <julian@richen.io>"
Key expired Tue 09 Jun 2020 19:16:34 BSTI 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?
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
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...
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.
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.
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.
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.
- No filesystem sandbox.
- No handling of dependencies.
- No first-party UI for managing multiple prefixes.
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.
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.
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.exeWINE 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.
"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?
(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.)
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?
That wouldn't be affected by HTTPS at all.
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.
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.
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".
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.
Does this set up and manage multiple isolated Wine & Proton environments?
> 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:
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.
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! :)
Thanks for this, it will make much easier to install linux on friends computers hehe
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".
Why not use Proton?
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)
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
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
I would love to have Fusion 360 working on Linux.
https://appdb.winehq.org/objectManager.php?sClass=applicatio...
"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?
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
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.
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...
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.
edit: though a VM can work too.
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.
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!
To make sure it was installed properly I tried Notepad++ and it worked flawlessly.
Office is just a bit of a pain.
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
(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 cost of it not withstanding, the OS itself is just janky. So. I’d prefer not to.
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.
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.
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.
Basically, just another Lutris/PlayOnLinux/whatever else.
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!