[Linux]If run from different folder, config is not found despite being in same directory as executable

[oerkel47]

I noticed this on Linux Mint, in Windows I never noticed this.
The problem became apparent when I created an autostart entry in .config/autostart and got the "config should be in same directory as executable" error when calling deej from anywhere that is not the deej folder.

A way to fix this could be like I've done in my fork. It's probably not perfect but it does the job for me.

edit: this problem also affects the edit config option from tray menu (not fixed in my fork)

[omriharel]

Hey @oerkel47, thanks for writing!

As you've pointed out, deej looks for its config file in a way that's relative only to the current working directory, rather than the location of the deej binary. The error being presented to the user is intentionally phrased in a less technical manner, which accounts for how most users run deej: by double-clicking the deej executable (or a shortcut they created to it). This implicitly runs from the directory where the binary is located (which is also where users are instructed to put the config file).

An additional fallback for looking for the config relative to the binary might be added in the future, but I am somewhat wary about doing this because it might confuse users with regards to which file is being loaded (without a great way to communicate this information).

If you'd like to avoid having to run modified source code just for this inconsistency, you can always set up your autostart entry to run deej from the binary's directory (either by passing a command that cds there first, or calling to an external shell script that does that). This should also result in the "edit from tray" option working once again.

Let me know if you have any questions :)

[oerkel47]

Hi @omriharel, thanks for the thorough reply.

You are most certainly correct that most people (Windows users) will not notice this as a problem at all. For the Linux users this might be different though, since autostarting deej is really what most people will want to do and the "startup application" app in Ubuntu/Mint/.. doesn't seem to make it possible easily.

you can always set up your autostart entry to run deej from the binary's directory (either by passing a command that cds there first, or calling to an external shell script that does that). This should also result in the "edit from tray" option working once again.

I actually tried this before via "cd ../deej && ./deej-release" and some derivations directly inside the autostart settings, didn't get it to work. Calling a script inside /deej folder works of course, but I was too stupid to detach deej from the shell so I went to the sourcecode. So I assume this is fixable for more Linux savy users, but working out of the box would be awesome!

Regarding confusing users if you add relative path support: Maybe I am missing someting, but I don't know how this could confuse anyone as the error messages would still work and now even be 100% technically correct!

While we are talking Linux things: the tray icon "edit config" only works if gedit is installed (default on Ubuntu but not Mint) and as far as I can tell it doesn't throw any error if it's missing. This should probably be its own issue though.

[omriharel]

Regarding confusing users if you add relative path support: Maybe I am missing someting, but I don't know how this could confuse anyone as the error messages would still work and now even be 100% technically correct!

That's a fair point. The part I was worried about was switching out the existing behavior, but it is true that anyone already successfully running deej will end up loading the same file they're loading now with this approach.

While we are talking Linux things: the tray icon "edit config" only works if gedit is installed (default on Ubuntu but not Mint) and as far as I can tell it doesn't throw any error if it's missing. This should probably be its own issue though.

Yes, I prefer to treat this in a separate issue (though of the top of my head, my thoughts are I don't want deej to have distro-specific logic for choosing the editor so we might end up just falling back to an error asking users to install gedit).