Wine manager Bottles has a big new release with major overhauls

There are plenty of Linux native options for ripping music CDs. I've been using K3B for years, and it works great, but there are many others if that's not to your liking.

Not exactly on topic, but did you try whipper as an alternative? I've been using it for my CD collection and it usually works just fine. It checks the rips against the musicbrainz database and pulls other metadata from there as well. I know that some people swear by EAC, but maybe this works for you.

https://github.com/whipper-team/whipper

Sadly.. due to my usage case, while Linux apps do a perfect job of ripping audio, the log files produced are not satisfactory.. let's just say it's for "not linux's fault" reasons and not entirely down to my own decision.

This is way to complicated to use and it don't feel user friendly at all and a stuff is missing or not working. i still feel like lutris is a better options here or if you somehow can miss mass this two.

Our focus is on ease of use. What and how should we improve?

Thanks for asking.

Unless I missed something while clicking around in your gui:
There should to be a way to specify multiple locations of bottles.
As we're installing sometimes huge applications in these WINEPREFIX'es, there needs to be a flexible way of storing in different locations. Like Steam has with its game library locations.

Sadly.. due to my usage case, while Linux apps do a perfect job of ripping audio, the log files produced are not satisfactory.. let's just say it's for "not linux's fault" reasons and not entirely down to my own decision.

Fair point. I'm not using those files personally, but remembered I saw them in my rip folders.

This is way to complicated to use and it don't feel user friendly at all and a stuff is missing or not working. i still feel like lutris is a better options here or if you somehow can miss mass this two.

Our focus is on ease of use. What and how should we improve?

Seeing as you're here and willing to answer questions, I have one: why have you (the Bottles devs) seen fit to re-invent the wheel and opt for a new, custom system for installing external requirements instead of using good ole Winetricks? On the one hand I can understand it (tighter control over the procedure and simpler/prettier to use because it's integrated right into the UI) but on the other hand it opens the door to an array of new issues, the main one being that some stuff that install just fine with Winetricks (notably the dontnet35 package) fail to do so with Bottles, because Winetricks takes into account possible Wine bugs and implements workarounds for them, while Bottles right now doesn't. Another issue is with the checksums, which seem to go bad every other day or so.

I'm all for having a tight GUI without external nuisances (like Winetricks, which is horrible as an app) but it should be made certain that at least the essential stuff (i.e. all the ones that you have implemented) Just Work™. And unfortunately, guaranteeing that the essential stuff Just Work™ means doing the necessary research and implementing workarounds for any and all obscure quirks - which is what Winetricks is all about.

Also, what the other guy/gal said: please make the prefix location configurable!

Sadly.. due to my usage case, while Linux apps do a perfect job of ripping audio, the log files produced are not satisfactory.. let's just say it's for "not linux's fault" reasons and not entirely down to my own decision.

Yarr!


Last edited by Nocifer on 29 Jan 2022 at 10:00 pm UTC

why have you (the Bottles devs) seen fit to re-invent the wheel and opt for a new, custom system for installing external requirements instead of using good ole Winetricks?

https://docs.usebottles.com/faq/where-is-winetricks#why-not-winetricks

why have you (the Bottles devs) seen fit to re-invent the wheel and opt for a new, custom system for installing external requirements instead of using good ole Winetricks?

https://docs.usebottles.com/faq/where-is-winetricks#why-not-winetricks

Yup, which pretty much sums up exactly what I said I think would be their reasoning - it's what I'd be thinking myself were I to try and do something similar. But my point is that Winetricks is what it is for a reason, and that reason is it takes care of any incompatibilities and quirks and makes sure everything installs correctly (at least that's the goal; sometimes things do break). If the Bottles system can't maintain the same level of functionality and credibility, then the Bottles system kind of fails. What I'm saying is that it needs much more love than it's currently getting, and sometimes the work that needs to be done is more complex than simply writing a .yml file.

If the Bottles system can't maintain the same level of functionality and credibility, then the Bottles system kind of fails. What I'm saying is that it needs much more love than it's currently getting, and sometimes the work that needs to be done is more complex than simply writing a .yml file.

On one hand, you're right.
We've all seen lots of systems that tried to reinvent the wheel but ultimately hit the same roadblocks the "original" wheels met and started to implement similar workarounds, ending up not much better, making a point for why reinventing the wheel was pointless to begin with.

On the other hand, you can do pretty much anything with .yml files, including more complex logic.
I don't see why you wouldn't be able to e.g. even write bash code (or Python, or whatever else can be parsed&executed at runtime) if it really was necessary for some use cases.

The real problem is adaptation and maintenance. If the main maintainer for winetricks stepped down, someone else is almost sure to take over.
Not sure what the situation would be with Bottles.
Personally, I strongly avoid using software that only has one main contributor. Been burned by that too often.


Last edited by TheSHEEEP on 30 Jan 2022 at 7:53 am UTC

Tried to use this but it seems way too buggy. Couldn't get vcruntimes installed even tho it went through the processes (games still couldn't see it), the command-line terminal and debug modes don't work (they just insta close).

Nice idea; too buggy for my liking, back to lutris!

On one hand, you're right.
We've all seen lots of systems that tried to reinvent the wheel but ultimately hit the same roadblocks the "original" wheels met and started to implement similar workarounds, ending up not much better, making a point for why reinventing the wheel was pointless to begin with.

On the other hand, you can do pretty much anything with .yml files, including more complex logic.
I don't see why you wouldn't be able to e.g. even write bash code (or Python, or whatever else can be parsed&executed at runtime) if it really was necessary for some use cases.

I wasn't trying to bash the .yml system, on the contrary. I recently had some time and contributed some additions/fixes to Bottles's dependencies, and I found the system refreshingly easy to work with. The self-contained .yml files are a great idea compared to Winetrick's massive wall of spaghetti code, and the logic behind them already supports lots of stuff necessary to describe the install procedure and can of course be enhanced with even more stuff if and when they're needed.

The problem arose when I tried to fix the .yml for dotnet35 (which currently doesn't install in Bottles) and after a while I realized that I was simply lacking the technical knowledge (and the time and/or will to look further into it) to understand why it doesn't work and what should be done in order to make it work - both questions which have already been answered by Winetricks, which is able to install the exact same dotnet35 in the exact same Bottle-created Wine prefix just fine.

The real problem is adaptation and maintenance. If the main maintainer for winetricks stepped down, someone else is almost sure to take over.
Not sure what the situation would be with Bottles.

And so it basically comes down to this. My issue is that maintaining a set of interdependent packages a la Winetricks, even in a much reduced number, requires more developer time than is currently available for Bottles (at least AFAICT). I'm not that worried about the future of Bottles as an app, because it's a good app and if anything it seems to be gaining more traction in the Linux community by the month, I just think it needs to make sure that the core functionality (like resolving and installing external dependencies) is working as tightly as it should before it opts to implement more QoL features like e.g. the installers.

I don't know, it's possible I'm making this into too much of an issue, especially when nowadays the external dependencies needed by the average gaming Wine prefix can be counted on the fingers of one hand (basically it's just the dx9 runtime plus maybe dotnet 3.5 and/or 4, maybe the vcruntimes, maybe some fonts, maybe Physx, and that's about it) so Winetricks is somewhat of an overkill anyway. Although to my defense, it's not my intention to make it into a big issue, I'm probably just peeved that I was not able to fix dotnet35 the other day :P

There should to be a way to specify multiple locations of bottles.

We have planned to implement it and will arrive soon, we are looking for the right workflow.

Seeing as you're here and willing to answer questions, I have one: why have you (the Bottles devs) seen fit to re-invent the wheel and opt for a new, custom system for installing external requirements instead of using good ole Winetricks? On the one hand I can understand it (tighter control over the procedure and simpler/prettier to use because it's integrated right into the UI) but on the other hand it opens the door to an array of new issues, the main one being that some stuff that install just fine with Winetricks (notably the dontnet35 package) fail to do so with Bottles, because Winetricks takes into account possible Wine bugs and implements workarounds for them, while Bottles right now doesn't. Another issue is with the checksums, which seem to go bad every other day or so.

I'm all for having a tight GUI without external nuisances (like Winetricks, which is horrible as an app) but it should be made certain that at least the essential stuff (i.e. all the ones that you have implemented) Just Work™. And unfortunately, guaranteeing that the essential stuff Just Work™ means doing the necessary research and implementing workarounds for any and all obscure quirks - which is what Winetricks is all about.

There are more reasons that led us to replace winetricks (we held it from 2017 to 2019) for our dependency manager:

- as you predicted the first reason is integration, this understood as integration of the entire Bottles infrastructure and not only the GUI (where the user must be able to have at least visual feedback of what is happening), the manager must be able to communicate harmoniously with all the components of the project (as is the case now)

- we needed a cleaner and more organized method for addictions, winetricks is a fantastic project but it is based on a file of infinite length, we want a repository that can be easily extended and which can handle a dependency tree for cascading installations

- we needed a method to manage dependency conflicts, being able to declare with which dependencies one conflict (not yet implemented)

- we wanted a faster method, winetricks in some cases can really take a lot of time while on Bottles it is faster for a series of factors given by the development and its structure (and the different methods by which they are installed in Bottles)

Regarding the problems with dotnet, there were a number of problems caused by an error in the Windows version change method. We have fixed it with latest update.

About checksums I don't know, winetricks also uses checksums to validate downloads, links and process are the same. Regarding having to constantly update them .. well it's a problem that also has winetricks but happens at most once a month if not more.

Regarding dependency manifests, we have been hit by some bugs but at the moment all methods (the actions) are fully functional and are constantly updated and extended release after release. We are writing documentation for maintainers explaining how to use each action, this should greatly facilitate the collaboration process. In any case, to date, to make a dependency, it is enough just to create its manifest, unless you need particular actions which are not available but it is enough to apply.

There are other details about this in the documentation.

This looks like a better Q4Wine.

This is not alternative to q4wine. With q4wine you can use your system Wine, with Bottles you cannot and this by design.

But you can. Search in the list of wine for sys-wine.

Better read docs and check which runners supported https://docs.usebottles.com/components/runners#types-of-runners.
Q4Wine is wrapper around your system/host wine, basically GUI for it with some tools and helpers which help you configure your system/host wine provided by your distribution or any other 3d-party wine build.

Bottles is designed around their own, custom pre-built versions of Wine with own ecosystem, tools and such and intended to work only with them.

There are plenty of Linux native options for ripping music CDs. I've been using K3B for years, and it works great, but there are many others if that's not to your liking.

Not exactly on topic, but did you try whipper as an alternative? I've been using it for my CD collection and it usually works just fine. It checks the rips against the musicbrainz database and pulls other metadata from there as well. I know that some people swear by EAC, but maybe this works for you.

https://github.com/whipper-team/whipper

Sadly.. due to my usage case, while Linux apps do a perfect job of ripping audio, the log files produced are not satisfactory.. let's just say it's for "not linux's fault" reasons and not entirely down to my own decision.

I'm curious what EAC can do that native Linux software can't.

This looks like evolving into a better variant of PlayOnLinux.

My first thought when I saw this was didn't I use this years ago? It looks a lot better now.

I like the idea of this, it would make it easier to run mod managers or other executables you might run along side a game than some other methods.
However I have had problems running things that run fine in Lutris, not sure if it a problem due to Flatpak installation or I just don't know how to use bottles properly.

There are plenty of Linux native options for ripping music CDs. I've been using K3B for years, and it works great, but there are many others if that's not to your liking.

Not exactly on topic, but did you try whipper as an alternative? I've been using it for my CD collection and it usually works just fine. It checks the rips against the musicbrainz database and pulls other metadata from there as well. I know that some people swear by EAC, but maybe this works for you.

https://github.com/whipper-team/whipper

Sadly.. due to my usage case, while Linux apps do a perfect job of ripping audio, the log files produced are not satisfactory.. let's just say it's for "not linux's fault" reasons and not entirely down to my own decision.

I'm curious what EAC can do that native Linux software can't.

The logs it creates during the ripping procedure are considered a golden standard in certain online circles.

I like the idea of this, it would make it easier to run mod managers or other executables you might run along side a game than some other methods.
However I have had problems running things that run fine in Lutris, not sure if it a problem due to Flatpak installation or I just don't know how to use bottles properly.

Yes, that's also another point against Bottles (at least in its current state; I have no doubt it will eventually be fixed). There's one specific game I have that in a Wine prefix created and configured by Bottles it will run with horrible graphical artifacts in DX11 mode (DX9 mode is OK) but when run externally (either via Lutris or simply via a normal wine call from e.g. the terminal) it will run perfectly fine. In both cases the prefix and its contents, as well as the Wine binaries used, are exactly the same (I use my system-wide Wine in both Bottles and Lutris).

Friendly hint: to easily run mod managers etc for games in Lutris, select the game you want, click the rightmost arrow in the toolbar that appears at the bottom (the one next to the Wine icon) and select "Run EXE inside Wine prefix" - et voila. One of those convenient little tricks that Lutris hides behind its terrible UI.

i still feel like lutris is a better options here or if you somehow can miss mass this two.

Lutris is useful when you have an specific game install script, but it lacks of a default generic script template for to use when a game or app doesn't have an specific install script...

I can't entirely agree because I install all my games without a script, and all my steam games are installed in wine, not native steam, but Steam EXE inside wine using lutris to download and install the game for me with the Steam for Windows runner. I can get most games up and running with no problem, even games like Resident evil Revelation and BLUE REFLECTION run as good as on native steam, and i don't have to worry about bit32 and proton 5.0 to make them work as long WMP 11 is installed. You can check out more on my channel

https://www.youtube.com/c/TheCasualGamers2020/videos

This is way to complicated to use and it don't feel user friendly at all and a stuff is missing or not working. i still feel like lutris is a better options here or if you somehow can miss mass this two.

Our focus is on ease of use. What and how should we improve?

My two biggest problems at the moment are 1. The Steam Runner doesn't work. I have to install it, Manuel, I don't know if I did it wrong, but it looks like the other runners do work of those I tried. 2. I can't install the Bottle in places other than my Home folder. I have a tiny SSD, so I can't use my main Folder as an established point thats why I have a 12 TB IronWolf for my games in the first place. If there is a way to use my second HDD, I would rather do that.


Last edited by kibasnowpaw on 31 Jan 2022 at 6:07 pm UTC

i still feel like lutris is a better options here or if you somehow can miss mass this two.

Lutris is useful when you have an specific game install script, but it lacks of a default generic script template for to use when a game or app doesn't have an specific install script...

I can't entirely agree because I install all my games without a script, and all my steam games are installed in wine, not native steam, but Steam EXE inside wine using lutris to download and install the game for me with the Steam for Windows runner. I can get most games up and running with no problem, even games like Resident evil Revelation and BLUE REFLECTION run as good as on native steam, and i don't have to worry about bit32 and proton 5.0 to make them work as long WMP 11 is installed. You can check out more on my channel

https://www.youtube.com/c/TheCasualGamers2020/videos

I am not talking about Steam games, I talk about games I have on DVD or Downloaded...
To Install Wolfenstein 2009 from a DVD (non-steam) was a pain in the ass.

Usage experience must be "Click game installer.exe file, Install game & Play"

I am not talking about Steam games, I talk about games I have on DVD or Downloaded...
To Install Wolfenstein 2009 from a DVD (non-steam) was a pain in the ass.

Usage experience must be "Click game installer.exe file, Install game & Play"

I don't have that game on disk, but i do have a lot of other games on disk.

Here are three games I installed from disk and run. I have not tried all my games. One I know I can't get to work is F.E.A.R because wine is fucking the CD key box op, so I can only put in 3 letters for every box when I need four letters, but besides that, I could easily run that game too.

https://www.youtube.com/watch?v=GEvm2-OBsxw

https://www.youtube.com/watch?v=3kFaB2Uiz6c

https://www.youtube.com/watch?v=zHAOqX3SDsM


Last edited by kibasnowpaw on 31 Jan 2022 at 6:50 pm UTC

There are plenty of Linux native options for ripping music CDs. I've been using K3B for years, and it works great, but there are many others if that's not to your liking.

Not exactly on topic, but did you try whipper as an alternative? I've been using it for my CD collection and it usually works just fine. It checks the rips against the musicbrainz database and pulls other metadata from there as well. I know that some people swear by EAC, but maybe this works for you.

https://github.com/whipper-team/whipper

Sadly.. due to my usage case, while Linux apps do a perfect job of ripping audio, the log files produced are not satisfactory.. let's just say it's for "not linux's fault" reasons and not entirely down to my own decision.

I'm curious what EAC can do that native Linux software can't.

The logs it creates during the ripping procedure are considered a golden standard in certain online circles.

Yes... "certain online circles".

This looks like a better Q4Wine.

This is not alternative to q4wine. With q4wine you can use your system Wine, with Bottles you cannot and this by design.

But you can. Search in the list of wine for sys-wine.

Better read docs and check which runners supported https://docs.usebottles.com/components/runners#types-of-runners.
Q4Wine is wrapper around your system/host wine, basically GUI for it with some tools and helpers which help you configure your system/host wine provided by your distribution or any other 3d-party wine build.

Bottles is designed around their own, custom pre-built versions of Wine with own ecosystem, tools and such and intended to work only with them.

And yet it is the only "runner" I use.