AntiMicroX / antimicrox

Graphical program used to map keyboard buttons and mouse controls to a gamepad. Useful for playing games with no gamepad support.
GNU General Public License v3.0
2.43k stars 141 forks source link

when I try to point antimicrox to a program instead of what I point it at it produces something like this. /run/user/1000/doc/SOMESTRING/PROGRAMNAME #707

Closed manoflinux closed 1 year ago

manoflinux commented 1 year ago

Is there an existing issue for this?

Current Behavior

when I use the dialog inside of antimicrox to point the exec command at an executable, it doesn't store the path and command I chose, it shows something like this. /run/user/1000/doc/SOMESTRING/PROGRAMNAME instead of something like this /usr/local/bin/PROGRAMNAME

But the problem is even if I point it at an executable and not a script, it doesn't honor the path so I get errors like this when running yad. /run/user/1000/doc/STRING/yad: error while loading shared libraries: libwebkit2gtk-4.0.so.37: cannot open shared object file: No such file or directory

If I point it at a script the script cant find any of the executables unless I put them in that /run/user/ format. I have never seen another linux program do this, can you please fix.

Expected Behavior

when I point AntiMicroX at a exectuable I expect it to return the full path like /usr/local/bin/yad instead of
/run/user/1000/doc/SOMESTRING/yad

Also would like it recognize normal paths in scripts and not have to put the executables path in /run/user format,.

Steps To Reproduce

click on a button click on cntrl click on advanced pull down till it says execute use the dialog to choose the file at that point just save it out and look in the file, although I think it shows it in the gui as well and you will see the program prefaced by ./run/user/1000/doc/SOMESTRING instead of the path you chose.

Environment

Program Version 3.3.2
Compiled from packaging: flatpak
Built Against SDL 2.24.0
Running With SDL 2.24.0
Using Qt 5.15.8
Using Event Handler: XTest
Compositor type: x11
Host OS: org.kde.Platform Version: 5.15-22.08 Architecture: x86_6

Anything else?

No response

manoflinux commented 1 year ago

forgot to say I tried it with the newest flatpak version as well same results.

pktiuk commented 1 year ago

Program Version 3.1

You are using ancient version of this app.

manoflinux commented 1 year ago

Program Version 3.3.2 Compiled from packaging: flatpak Built Against SDL 2.24.0 Running With SDL 2.24.0 Using Qt 5.15.8 Using Event Handler: XTest Compositor type: x11 Host OS: org.kde.Platform Version: 5.15-22.08 Architecture: x86_6

what about this version? is this new enough? because it has the same issue.

manoflinux commented 1 year ago

That is on 3.3.2 image

pktiuk commented 1 year ago

Flatpak packages work in sandboxes, so they often cannot access some of the files in the general system. You can try to edit these settings with apps like flatseal I recommend you investigate this first.

manoflinux commented 1 year ago

image same, I gave it all the file permissions with flatseal and closed flatseal and reopened it to make sure they took. even went back and gave it more permissions. I will try compiling it when I get a chance and see if that changes anything.

pktiuk commented 1 year ago

This strange path is a good one, because this is how it looks like from inside of the sandbox.

If you want to have any interaction applications/files outside of your regular user directories (like /home/name/Downloads,/home/name/Documents...), then just use classical packages (you can try also with AppImage).

pktiuk commented 1 year ago

I guess this one can be closed now