Wine manager Bottles has a big new release with major overhauls

Quoting: Mountain ManThere 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.

Quoting: iskaputtNot 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.

Quoting: mirkobrombin

Quoting: kibasnowpawThis 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.

Quoting: BlackBloodRumSadly.. 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.

Quoting: mirkobrombin

Quoting: kibasnowpawThis 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!

Quoting: BlackBloodRumSadly.. 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 January 2022 at 10:00 pm UTC

Quoting: Nociferwhy 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

Quoting: whizse

Quoting: Nociferwhy 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.

Quoting: NociferIf 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 January 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!

Quoting: TheSHEEEPOn 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.

Quoting: TheSHEEEPThe 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

Quoting: chrisqThere 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.

Quoting: NociferSeeing 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.