[Bug]: Bottles creates the desktop file with the wrong command.

[onurbbr]

Describe the bug

Desktop extension created applications do not work.

The -b extension of the bottles-cli command is supposed to be the name of the bottle, but instead shows the bottle's location. For this reason, it does not open.

As a sample piece of command I can show it like this: Exec=bottles-cli run -p 'Need For Speed Most Wanted' -b '/mnt/HDD/Games/CustomLibrary/Bottles/Gaming' Bottles generates the command as above.

The command I created is as follows: Exec=bottles-cli run -p 'Need For Speed Most Wanted' -b 'Gaming' It works like a charm with my command.

To Reproduce

1. Open the bottle you created through the application
2. Create desktop shortcut of any application.
3. Run the app via desktop file. See the error.

Package

AUR ("bottles" package)

Distribution

Arch Linux

Troubleshooting Logs

Version: 2022.7.28-brescia-1
Display:
    X.org: true
    X.org (port): :0
    Wayland: false
Graphics:
    vendors:
        nvidia: &id002
            vendor: nvidia
            envs:
                __NV_PRIME_RENDER_OFFLOAD: '1'
                __GLX_VENDOR_LIBRARY_NAME: nvidia
                __VK_LAYER_NV_optimus: NVIDIA_only
            icd: /usr/share/vulkan/icd.d/nvidia_icd.json
        intel: &id001
            vendor: intel
            envs:
                DRI_PRIME: '1'
            icd: ''
    prime:
        integrated: *id001
        discrete: *id002
Kernel:
    Type: Linux
    Version: 5.18.14-zen1-1-zen
Distro:
    Name: Arch Linux
    Version: Unknown
Disk:
    Total: 250851127296
    Free: 99508801536
RAM:
    MemTotal: 15.5GiB
    MemAvailable: 10.9GiB
Bottles_envs: null
Tools and Libraries:
    cabextract: true
    p7zip: true
    patool: true
    glibc_min: '2.35'
    icoextract: true
    pefile: true
    orjson: true
    markdown: true
    ImageMagick: true
    FVS: true
    xdpyinfo: true

Display Protocol

X11

Display Backend used by Bottles

X11

Additional context

Note: Since the Bottles package was out-of-date in the AUR, I manually updated the package. There is no problem with the operation of the package.

[onur@archlinux ~]$ yay -Qi bottles Name : bottles Version : 2022.7.28-1 Description : Easily manage wine and proton prefix Architecture : x86_64 URL : https://github.com/bottlesdevs/Bottles Licenses : GPL3 Groups : None Provides : None Depends On : python-pefile gtksourceview4 libhandy imagemagick lib32-gnutls gtk4 gtksourceview5 hicolor-icon-theme dconf python gtk3 patool p7zip python-gobject python-requests python-yaml python-markdown wine cabextract webkit2gtk xorg-xdpyinfo icoextract Optional Deps : gvfs [installed] vkd3d [installed] lib32-vkd3d [installed] lib32-vulkan-icd-loader [installed] vulkan-icd-loader [installed] gamemode [installed] Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 2.45 MiB Packager : Unknown Packager Build Date : Fri 29 Jul 2022 09:35:41 PM +03 Install Date : Fri 29 Jul 2022 09:35:46 PM +03 Install Reason : Explicitly installed Install Script : No Validated By : None

https://user-images.githubusercontent.com/47495526/181903003-1498fe60-5695-43c0-9a57-f44e307770cd.mp4

[axtloss]

I'm not able to replicate this issue on the latest bottles release from flathub, even though the bottles code does seem to add the path to the exec line: https://github.com/bottlesdevs/Bottles/blob/a7a96296302da6bcbab3b6617845b37ed6e98681/src/backend/utils/manager.py#L245

[onurbbr]

When I try from the command line, it cannot find the location, but when I enter the bottle name, the application works.

[onur@archlinux ~]$ bottles-cli run -p 'Need For Speed Most Wanted' -b '/mnt/HDD/Games/CustomLibrary/Bottles/Gaming' 11:54:58 (INFO) Forcing offline mode Bottle /mnt/HDD/Games/CustomLibrary/Bottles/Gaming not found [onur@archlinux ~]$ ls -l /mnt/HDD/Games/CustomLibrary/Bottles/Gaming total 6424 -rw-r--r-- 1 onur onur 2408 Jul 30 11:15 bottle.yml drwxr-xr-x 2 onur onur 4096 Jul 30 11:55 dosdevices drwxr-xr-x 7 onur onur 4096 Jul 29 22:55 drive_c -rw-r--r-- 1 onur onur 23 Jul 30 11:55 dxvk.conf drwxr-xr-x 2 onur onur 4096 Jul 30 11:50 icons -rw-r--r-- 1 onur onur 5600690 Jul 30 11:55 system.reg -rw-r--r-- 1 onur onur 4052 Jul 29 22:51 userdef.reg -rw-r--r-- 1 onur onur 947271 Jul 30 11:55 user.reg [onur@archlinux ~]$ bottles-cli run -p 'Need For Speed Most Wanted' -b 'Gaming' 11:55:08 (INFO) Forcing offline mode Windows path detected. Avoiding validation. gamemodeauto: fsync: up and running. wine: Using setpriority to control niceness in the [-11,11] range 002c:err:wineboot:process_run_key Error running cmd L"C:\windows\system32\winemenubuilder.exe -r" (2). 00dc:err:xrandr:xrandr14_get_adapters Failed to get adapters 00d4:err:xrandr:xrandr14_get_adapters Failed to get adapters gamemodeauto:

Rather, the -b option on the command line is specified as the bottle name, not the path.

[onur@archlinux ~]$ bottles-cli run -h usage: bottles-cli run [-h] -b BOTTLE [-e EXECUTABLE] [-a ARGS] [-p PROGRAM]

options: -h, --help show this help message and exit -b BOTTLE, --bottle BOTTLE Bottle name -e EXECUTABLE, --executable EXECUTABLE Path to the executable -a ARGS, --args ARGS Arguments to pass to the executable -p PROGRAM, --program PROGRAM Program to run

[mirkobrombin]

No. -e is for executable -p for a program name -b for the bottle path (which is the key Path) in the bottle config file

[axtloss]

As already stated, I'm not able to replicate this issue, bottles creates the right desktop entries for me:

[onurbbr]

No. -e is for executable -p for a program name -b for the bottle path (which is the key Path) in the bottle config file

Yes I saw this via command line.

I'm not able to replicate this issue on the latest bottles release from flathub, even though the bottles code does seem to add the path to the exec line:

https://github.com/bottlesdevs/Bottles/blob/a7a96296302da6bcbab3b6617845b37ed6e98681/src/backend/utils/manager.py#L245

According to what you said, isn't it wrong in the code here?

As already stated, I'm not able to replicate this issue, bottles creates the right desktop entries for me:

I installed it via AUR. I didn't use Flatpak.

[axtloss]

According to what you said, isn't it wrong in the code here?

The code to me seems wrong, but it isn't since it works for me, have you tried using the flatpak to see if that fixes it?

[onurbbr]

According to what you said, isn't it wrong in the code here?

The code to me seems wrong, but it isn't since it works for me, have you tried using the flatpak to see if that fixes it?

I didn't try. I will try.

[mirkobrombin]

The bug is with bottles stored in external paths and should be fixed by https://github.com/bottlesdevs/Bottles/commit/ddd2bbb9699590b18cfaa95c14da77c91b5166a1

The bottle name is not unique so we need another key to detect the right bottle and this is why we use the key Path instead. Before this commit, bottles were listed using the bottle folder name which may be incorrect when comparing with a key Path of a bottle stored in external locations (since the key Path will result in a full path and then mismatch with just the folder name).

This fix works but will require the user to use the right key Path.

[mirkobrombin]

I confirm that the commit solved the problem.

Fixed by https://github.com/bottlesdevs/Bottles/commit/ddd2bbb9699590b18cfaa95c14da77c91b5166a1

[onurbbr]

According to what you said, isn't it wrong in the code here?

The code to me seems wrong, but it isn't since it works for me, have you tried using the flatpak to see if that fixes it?

I tried from Flatpak and yes it works fine.

[onurbbr]

According to what you said, isn't it wrong in the code here?

The code to me seems wrong, but it isn't since it works for me, have you tried using the flatpak to see if that fixes it?

I think when you install the prefix somewhere other than ~/.local/share/bottles/bottles, it writes the path of the bottle directly to the bottle name. I think it would make more sense to use the name instead of using the bottle path. Because the bottle name must be unique. The bottle you installed runs the applications under the location I mentioned above in flatpak. That's why you perceive it correctly. When I do this without changing the location, it works properly. The reason why I install the applications in different places is that I do not have much system space, so I install them on the hard disk. Anyway, I can fix this manually. Thank you for your attention and for offering this application to us. Good work.