Added Linux support

[cartaplassa]

Tested w/ custom defaultpath and custom game path at the same time, everything's working

[cartaplassa]

Haven't tested on Windows tho

[shadoxxhd]

1. since tkinter is already imported as tk, it is better to just use tk.messagebox instead of directly importing it
2. checking for which steamcmd might be useful in win32 too, but makes it more difficult to find the downloaded mods (when not using default destination). Perhaps prefer steampath, and change defaultpath if which steamcmd and not yet installed in steampath? (non-essential for merge, more note to myself)
3. does creationflags=subprocess.CREATE_NO_WINDOW throw an error, or is it just unneccessary?
4. right now, expanduser is not used consistently under win32 (eg. missing in line 68)
5. steampath variable is useless if invoking steamcmd exclusively through path on linux

other than that, it looks good

[cartaplassa]

1. I guess Messagebox is a subpackage and needs to be imported as such. This happens when it's called as tk.messagebox: >>> test = tk.messagebox.askokcancel() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: module 'tkinter' has no attribute 'messagebox'

from tkinter.messagebox import askokcancel also works fine, I just thought it would be better for readability.

2. Thing is, I'm kinda newbie in Linux and afaik there are dozens of paths that different package managers can put the packages into, so my path, /usr/bin/steamcmd, might not work for everyone and that was the only universal way to check if steamcmd is present that I came up with.
3. Yeah, this happens: <class 'AttributeError'>module 'subprocess' has no attribute 'CREATE_NO_WINDOW'. I googled it and it seems like on Windows Popen opens terminal by default, but on Linux it doesn't and, well, that's about it.
4. And 5. I got a bit confused there, because SteamCMD (in whatever location it is) will download the mods in the correct Steam folder (or it seems like if Steam itself isn't present it will still figure out the correct path where it should be). But after that, when SWD checks location and moves the mods to wherever they need to be (line 147 and onwards), it must have the steampath present and set to Steam installation folder (~/.local/share/Steam). And that's where tilda needs to be translated to /home/<user> expression or Python will create a folder "~" in the SWD directory. Same thing with defaultpath. And that's kinda the whole purpose for os.path.expanduser() here. Windows is a different story: tilda symbol isn't usually used that way. Steam's default path should be in C:/Program Files and if defaultpath needs to be specified, isn't it easier to just copy and paste it from explorer? So calling os.path.expanduser() will just return the same path it was given. But if it's not the case, tell me how to improve it and I'll do it.

[shadoxxhd]

1. Thanks for the explanation ✔️
2. There appears to be no really convenient universal solution; default-configuring steampath to which steamcmd, always prefering which steamcmd and adaptive changing of defaultpath (for moving mods afterwards) all have their own disadvantages. I'll look over this later.
3. ✔️
4. On windows, steamcmd is usually installed seperately from steam, since it is not part of the normal steam installation and afaik not guaranteed to integrate safely. Therefore, downloads usually occur inside the steamcmd folder, whereever that may be. So if someone has a tilde in their steampath, it should (on windows) apply to steamcmd.exe as well as mod downloads. Probably won't cause problems very often due to ~ being unusual for windows, but it's still nice if all parsings of steampath behave consistently.
5. I didn't think about the need to know mod download destination when using which steamcmd. If it downloads to ~/.local/share/Steam by default on linux, and steampath is set to that, it might cause security issues with someone placing an executable in that location (if which steampath is only used as a fallback). Is that path sufficiently standard to hard-code? Otherwise it might be useful to disable automatic mod movement on linux completely, since it's very easily accomplished by a simple shell script anyway, in a much more comfortable way than possible with windows scripting solutions (batch or powershell). Having seperate paths for the executable and the download location would appear to necessitate an additional optional dlpath option, in case which steamcmd doesn't find an installation distinct from the download directory.

[cartaplassa]

Yeah, it makes a lot of sense. So, separate default steampath is gone and, if I understand correctly, steamcmd will figure out the destination folder by itself and SWD will print it in the output field. So, the only thing user has to do is copy it and paste in .ini before specifying the desired moving path if need arises, which shouldn't be that big of a problem. Therefore, I guess it's done.

Line 112 was for testing purposes, just forgot to remove it in previous commits