Bottles v2

Easily manage wineprefix using environments

⚠️ This version is under development. Here you can find the stable v1.

Help Bottles speak your language 🗣️

Read here how to translate Bottles in your language or how to help improve existing ones.

Features

Create bottles based on environments (a set of rule and dependencies for better software compatibility)
Access to a customizable environment for all your experiments
Run every executable (.exe/.msi) in your bottles, using the context menu in your file manager
Integrated management and storage for executable file arguments
Support for custom environment variables
Simplified DLL overrides
On-the-fly runner change for any Bottle
Various optimizations for better gaming performance (esync, fsync, dxvk, cache, shader compiler, offload .. and much more.)
Tweak different wine prefix settings, without leaving Bottles
Automated dxvk installation
Automatic installation and management of Wine and Proton runners
System for checking runner updates for the bottle and automatic repair in case of breakage
Integrated Dependencies installer with compatibility check based on a community-driver repository
Detection of installed programs
Integrated Task manager for wine processes
Easy access to ProtonDB and WineHQ for support
Configurations update system across Bottles versions
Backup bottles as configuration file or full archive
Import backup archive
Importer from Bottles v1 (and other wineprefix manager)
.. and much more that you can find by installing Bottles!

Work in progress

Installer manager #55
Import backup configuration
Optional sandboxed bottles

Install 🔧

Disclaimer: This is a development version (alpha), you will find bugs, black holes and monsters under the bed. Be careful.

Unofficial packages

These packages are maitained by our community but not officialy supported.

Distro	Package Name/Link	Maintainer
Arch Linux	`bottles-git` (AUR)	Talebian12
Arch Linux	`bottles` (AUR)	ragouel
Tumbleweed	`bottles`	WhiXard
Fedora 33	`bottles`	WhiXard
Void linux	`bottles`	andry-dev

Notices for package maintainers

We are happy to see packaged Bottles but we ask you to respect some small rules:

The package must be bottles, in other distributions it is possible to use suffixes (e.g. bottles-git on Arch Linux for the git based package) while on others the RDNN format is required (e.g. com.usebottles.bottles on elementary OS and Flathub repository). All other nomenclatures are discouraged.
In the current development phase, the version corresponds to the formula (2.commit, e.g. 2.a005f01), where possible use this formula throughout the development phase. For stable and 'stable development' release you can use the version in the VERSION file and its release. Please don't travel into the future with releases. It might confuse users.
Do not package external files and do not make changes to the code, no hard script. Obviously with the exception of files essential for packaging. Once the package is published, you can open a Pull Request to add it to the packages table above! Thanks ❤️!

Build with meson 👷

Instead of use the Appimage you can choose to build your own Bottles from source.

Build

mkdir build
meson build && cd build
ninja -j$(nproc)
sudo ninja install

Uninstall

cd build
sudo ninja uninstall

Common issues

There are no other problems. Are we good? 👀

Bottles was born in 2017 as a personal need. I needed a practical way to manage my wineprefixes. I hate the idea of using applications that install me a version of wine for each application and I decided to create this application, based on the concept of using one or more wine prefixes as a "container" for all my applications.

In 2020 thanks to Valve, we have access to Proton. An optimized version of Wine for gaming. Thanks also to other projects like DXVK/VKD3D/Esync/Fsync/Shader compiler and others, we can run a large set of video games designed for Windows, on Linux.

The idea of creating an environment-based wineprefix manager comes from the standardization of dependencies and parameters necessary to run a game. On the other hand, we have software (often not up to date) that require environments and configurations different from those used in gaming. Hence the idea of managing separate environments.

Why not just POL or Lutris? 🤓

Because they are similar but different applications. I want to create environments that contain more applications and games and where the wine version can be updated.

I also want to be able to export my bottles allowing easy sharing, with or without applications. In POL/Lutris we have the concept of "with this version of wine and these changes it works". In Bottles the concept is "this is my wine bottle, I want to install this software".

The goal with this version is also to integrate with the system in the best possible way. Being able to decide in a few bottles to run an .exe/.msi file and have control over it without having to open Bottles for each operation.

Bottles is close to what wineprefix means, since v.2 it provides a simplified method to generate environment-based bottles and thanks to other tools it simplifies the management but nothing more.

weblate / bottles Goto Github PK

bottles's Introduction

bottles's People

Contributors

Stargazers

Watchers

Forkers

Recommend Projects

Recommend Topics

Recommend Org