Restructure the thcrap directory

[brliron]

I've always been bothered by the number of things in the root of the thcrap directory. When the user opens thcrap_brliron.zip, he sees a lot of things, and he has to figure out which one he should run. Us programmers know that we should look for exe files, but people who are bad with computers... There's a reason Windows hides extensions by default. And I'm working on something that would allow us, among other things, to move the thcrap_configure.exe and thcrap_loader.exe to a subdirectory (by adding a tiny exe file that will just execute the exe files in the subdirectories). Also, there have been some discussions about moving all the repositories (Bravi, dass7, DTM, nmlgc, thpatch etc) to a subdirectory. So I think this is a good time to restructure the thcrap directory, and I'm opening a general question: what do we want it to look like? I'm dropping some ideas, please comment and/or add other ones.

Move everything to a subdirectory

Just keep the runnable files in the root, and dump everything to a subdirectory (it could be named data, or something else). data:

Have one directory per "type" of file/directory

To keep things organized, while keeping just the runnable things in the root. I don't trust the end users, but I still think they can find the exe files. It could look like this: binaries: config: patches:

Both

Keep only the runnable things in the root (like in the 1st one), but also organize things in the data directory (instead of dumping everything there). data: data/binaries: data/patches:

These ideas are general architectures, don't stop at the details, like "the binaries should be called 'bin' or 'in the Both structure, logs should be in a logs directory' (at least don't do it now, we'll do it later). I think I prefer the last one. Or... I'm not sure.

---

Some related questions:

• I wonder, are we allowed to put the UNLICENCE file in a subdirectory? Do we need to join it in the releases, or it is enough to have it on Github?

• Do we really need to put the README.md in the releases? I think this readme is good for the Github home page, but not so good when it comes to providing useful information to the end users. And it's in .md format, Windows don't know how to open them, so the average user won't know either. If we keep it, we should at least rename it to .txt. But I think a good UI should replace the need for a readme.

  Also, we need to think about something to update from the old structure to the new one, and stop shipping thousands of 0kb files in the root directory. But this can wait for later.

[nmlgc]

One of the ideas I never got to implement would have been to restructure the directory according to the XDG Base Directory specification, at least for semi-native Linux versions of thcrap. This would have been pretty close to the "one directory per type of file" idea, where config/ would have gone into $XDG_CONFIG_HOME, and patches/ into $XDG_CACHE_HOME for remotely synced patches and $XDG_DATA_HOME for your locally developed ones.

Some more thoughts:

• scripts/ could go directly under binaries/. If things go my way, we're going to move away from Python, and no matter whether we end up going with C# or Rust, the replacements are going to be binaries as well.
• Logs can still be in the thcrap root directory, I think. It's only two files after all. That's debatable, though.
• I agree about the README. If the restructuring happens before the good UI though, we should at least replace it with a short text pointing back to this GitHub repo.
• I also agree with putting thcrap_loader.exe under binaries/.
• Renaming the run configuration .js files to .thcrap while we're at it would also be a good idea. Allows us to not only register a nice UI for this file extension specifically, but also makes it easier for third-party tools like the Universal THCRAP Launcher or thpiss to filter those files.
• Also, here's a revolutionary idea: Directory names starting with capital letters, for that extra piece of user-friendliness. :tannedgod:

[DankRank]

• I agree with most points from nmlgc, except the last one about Directory names starting with capital letters. I find it difficult to type such filenames on Unix systems.
• Have one directory per "type" of file/directory pls. The first variant would just keep the mess, but hide it from the user. The Both isn't that nice either, it replaces 3-4 directories with 1, at the expense of having one extra directory level and some messiness in the data.
• IMO config.js and games.js should be separate from run configurations, but I guess it's ok if we're changing extensions to .thcrap
• Having separate directory for locally developed patches might be a good idea
• Technically, we don't even need to bundle the UNLICENSE file :tannedcirno:
• Obligatory bikeshed: s/binaries/bin/ s/patches/repos/

[brliron]

I agree with most points from nmlgc, except the last one about Directory names starting with capital letters. I find it difficult to type such filenames on Unix systems.

Well, I don't know about you, but my grandma doesn't type filenames on Unix systems. I think 1% more pain for 1% of users in exchange for 2% more friendliness for 99% of users is a fair tradeoff (even Ubuntu uses directory names starting with capital letters).

The Both isn't that nice either, it replaces 3-4 directories with 1, at the expense of having one extra directory level and some messiness in the data.

Ignore the messiness, that's part of the details, we can have Both with a logs and a config directory, and nothing at the top level. And the point of the Both one is to replace 3-4 directory with 1, to hide as many things as possible to the user. I'm not sure this one improves the user-friendliness a lot, but I have a friend that thinks it's really important. I just asked my older sister and she thinks it would be better. I should ask my parents too.

[DankRank]

Ubuntu uses directory names starting with capital letters

That's actually my pet peeve with most DEs :tannedgod: It wouldn't make much a difference, since the directory names would still be cryptic for the average user. Most people probably don't even capitalize their own stuff. My computer illiterate friend sure does not. :tannedcirno:

Both

It's 3 directories, and one executable file with a fancy icon. If your user can't figure out which one to click, having just one directory won't save them. You'd just increase their success rate from 25% to 50%.

I don't really think any of this will significantly improve UX for the kind of user you're describing. There are bigger hurdles like installing software from an archive, or finding the download link on the website. Finding the right thing to run is probably one of the easiest things in thcrap, thanks to the icons. If you really want to increase user-friendliness for dummies, an installer is the way to go.

I think it is better to be slightly confusing a single time for the absolute illiterate, than be mildly annoying every time for the 1% which actually needs to open these directories.

[hoangcaominh]

Why can’t we just put the patch shortcuts to the desktop? Or you can give users another opinion where those shortcuts are put in a subdirectory.

[IgoSplashman]

patch shortcuts to the desktop

I don't want +100 thcrap shortcuts to clutter my desktop, thanks. It's messy enough as it is. Option for shortcuts into sub-directory sounds like an idea.

[ahiijny]

I like "Have one directory per "type" of file/directory". It looks organized, and it's also consistent with what I've seen in lots of other program directory structures. "Both" could also work.

"Move everything to a subdirectory" just feels unpleasant (it's like the equivalent of shoving the mess into the closet so that the room is clean).

Some random comparisons with programs that I have lying around, in no particular order:

• Orbiter 2010 + a bunch of DanSteph mods:
  
• Osu!:
  
• Paint Tool Sai:
  
• Freeplane:
  
• MuseScore 2:
  
• Renpy:
  
• Notepad++:
  
• Eclipse:
  
• Code::Blocks:
  
• Git:
  

  ---

  patch shortcuts to the desktop

  I don't want +100 thcrap shortcuts to clutter my desktop, thanks. It's messy enough as it is. Option for shortcuts into sub-directory sounds like an idea.

+1 That's how I have it set up on my computer right now. I put a shortcut to the thcrap folder on my desktop.

[brliron]

I made a poll on our Discord, and... I didn't expect the result to be that one-sided. (1 is Have one directory per "type" of file/directory and 2 is both)

Okay, now we can go into more details: which folders do we need, and what do we put in them?

Binaries and patches

I don't think anyone is against a folder for binaries and DLLs (binaries in my example above, we'll discuss the names later). I also think we need a folder for patches. I'm not sure we need a folder for locally developed patches. Outside of the XDG thing, the only upside I see is that local_patches/my_awesome_patch is a bit easier to access than patches/brliron/my_awesome_patch, with the downside of having to document that feature (and nobody will read the documentation, so everyone will keep using remote_patches/username/awesome_patch). And about XDG, can we have $XDG_CACHE_HOME defaulting to patches/ and $XDG_DATA_HOME defaulting to patches/local/ ?

Scripts

Nmlgc is right, scripts can go under binaries. Even if we keep them as scripts, they are still quite the same as binaries.

Unlicence and readme

We can remove UNLICENCE.txt. We need a small readme.txt that will replace the README.md. It has to be in a format a clean Windows can open with a double-click, so .txt seems a good choice. It needs to be at the root.

thcrap_loader

About thcrap_loader.exe, I can think of one reason to keep it in the root: there are already some things that assumes it will be at the root (the Steam guides for example). But I still don't like to have it at the root. And the "loader" in its name makes me think about a launcher. It will have a copy in the binaries directory (because all the DLLs are there). But do we keep a copy in the root? (not actually a copy, rather a stub that just runs the original. But that's a detail) We can also keep both for a while, then remove the one at the root later. I don't think that's a solution. We can also remove it for new installations, and keep the one at the root only for people upgrading from the old directory structure. We can also remove it from the zip release, and create it with the shortcuts when the user runs thcrap_configure. I think I prefer remove it for new installations, and keep it only for people upgrading. Or if it would be too confusing, keep both forever.

Logs

I'm not sure about them. I'll think more about it later, you can discuss it now if you want.

Shortcuts

This is a big one. First, they won't stay as shortcuts, they will also be replaced with small stubs that runs thcrap_loader. Or... The main advantage of stubs is that they can have a relative path to thcrap_loader (while shortcuts can't). But if they have a relative path, you can no longer move them. Maybe we want to keep using shortcuts when they have absolute paths, and use stubs when they have relative paths? Also, we need to take into account the Universal THCRAP Launcher, which will probably be included in the thcrap releases as part of this restructuring. So, we could have only thcrap_configure and the universal thcrap launcher at the root. Still, not everyone want to use the launcher. The stubs / shortcuts should still exist somewhere. This can be in the root, in a subdirectory, or on the desktop / start menu. If it's on the desktop / start menu, I think thcrap_configure must ask before creating them. And I still think thcrap_configure could create a portable installation some day, and if it creates a portable installation for one game, the stub should be at the root. Most installers have a checkbox to create shortcuts on the desktop. But thcrap_configure can't display checkboxes (at least not yet).

Configs and stacks

We have 3 files: config.js, games.js and en.js (or any other patch stack). I think we can just dump them all in a single directory (patch stacks will move to a .thcrap extension, games.js and config.js will keep the js extension, or move to a .json extension). Most users will have only one, or maybe 2, patch stacks, we don't need a whole directory just for them.

That was a lot of text. And I'm quite sure I forgot something.

[nmlgc]

local_patches/my_awesome_patch

That would imply that local_patches is a single repo, rather than a root directory for multiple repos, which is what I was thinking about. Which would negate your one upside, so I agree, it's only a minor thing that we shouldn't need to worry about at this point. Heck, I'd be quite happy already if we just got people to not make their funny one-off mods by manipulating files directly in thpatch/lang_en. Marking files as read-only would start out as more annoying since that attribute is preserved when copying files in Explorer. Sure, we could put a Read this before editing anything in here.txt in the root directory of any remote patch where we explain all this. But still, adding a local_patches directory would make even this file longer, and the resulting directory structure harder to navigate. So I don't see this happening until we've got an IDE of sorts that introduces actual benefits for patch authors when compared to editing files in Explorer and a plaintext editor.

thcrap_loader

I don't think one additional executable matters that much. On the contrary, I'd say it improves discoverability of thcrap_loader's command-line options for power users, whereas in binaries/, it would be hidden under all those Visual Studio 2019 CRT DLLs. You might argue that this is unnecessary after we have stub executables, but those still have to be created by something, and you'll always be able to bypass that. Then again, the same could be said of the scripts, and thcrap_loader is basically one of those, especially after all the UX improvements that further try to get rid of it for average users. Then again…

some things

As in, every single already existing shortcut, meaning that the update would involve looking at every single .lnk file on the entire system and adjusting its path if necessary. Which we'd have to do in any case before we remove it from the root. So yeah, we absolutely must keep it for existing installations.

Removing it from the root for new installations… well, yeah, how much do we care about existing guides. After my recent terrible experiences with Moriya Shrine, I'm tempted to say "not at all"… but that's just me.

The responsible option would be to have our own slick, responsive, and modern-looking thcrap download web page, localized into all active languages, under our control that explains everything you'd typically write a guide for. Having this stuff on a typical MediaWiki download page apparently doesn't cut it, given the number of times I encounter people struggling to combine thcrap with vpatch… And while we lack the funds and manpower to fix those issues for real, we might just come across some web designer who is willing to take our Open Collective money in exchange for 1) such a site, and 2) keeping in touch with our future developments that might actually fix some of those underlying issues after all.

Or we could just keep it forever and avoid all this.

[brliron]

We now have one commit towards the restructuring, and more will follow, so it's time to discuss names. First, a note about directory names starting with a capital letter. I still think it would be better, but I can't do anything else than repeating "I think the users would prefer it" over and over to convince people, and it isn't important enough for a poll (and you could argue that a poll is irrelevant), so I'll stop here.

Now, binaries. I think I want a scary name, that says "don't click here if you don't know what you're doing". That's why I would go for "binaries" rather than "programs", " executables" or something like that. As for "bin", I think it's just too short to mean anything, in that, it's less scary than binaries.

config: contains at least config.js and games.js. Can also contain the patch stacks. I don't want to create 1 top-level directory for every file, I think we can keep them together under the generic name "configuration". It's not like normal end-users change these files without being told to. For the name, I would go for "configuration" or "config". I don't know which one is better. I think "conf" or "cfg" is too short to be understandable, and "patch stacks" is too technical.

logs: I like the idea of having only runnable things in the top-level directory, and maybe you can just drag this folder onto Discord to send all the logs? So I think they should have their own directory. As for the name, I like "logs" as a developer, but I don't think I knew what it is before being a developer. "Send this in case of trouble" is way too awkward as a directory name. And I can't find a better word. Any idea?

repos: I don't like the name "repo", or even "repositories". It doesn't mean anything. Well, it does mean something for the git users, but even most third-party models don't know how to get. And this directory do contain patches after all, that's why I used "patches" in my screenshot earlier.

thcrap_loader.exe: already discussed above, we can't move it and we can't rename it.

thcrap_configure.exe: I guess we will keep it's name consistent with thcrap_loader. Or... on the contrary, we may want to give it (and UTL) a user-friendly name, and keep a more scary name for thcrap_loader, to incite people to click on the friendly ones. After all, that's the reason thcrap_configure has an icon and thcrap_loader doesn't.

shortcuts: 2 choices:

• Promote UTL as the recommended way to run thcrap. In this case, we'll just shove the shortcuts in a subdirectory, keeping them here only for scripting, adding to the Steam library etc.
• Keep the shortcuts as the recommended way to run thcrap. In this case, I think we need to keep the shortcuts at the top-level, so that they are discoverable (we can add a checkbox, off by default, to put the shortcuts in a subdirectory).

I'm an old grump, I grew with the pre-restructuring thcrap, and I don't like changing my habits, so I would tend to choose to keep shortcuts as the recommended way to run thcrap. But the more I think about it, the more recommending UTL seem a good idea. As for the name, I don't think "shortcuts" would make sense for the end-users, and it will be wrong anyway because we'll switch to tiny exe files. Would "launchers", "game launchers" or "games" make sense? That's all I can think about.

Readme: the result of the discussion was " we don't need the big readme.md, just something with our github url until we have a gui". UTL have a github button, and it will be included. So, no readme.

Please discuss. If nobody answers, I will assume everyone is fine with these names.

[32th-System]

We could keep the names thcrap_configure and thcrap_loader but encourage people to click thcrap_loader if they want open UTL because thcrap_loader would run UTL located in binaries/ if it gets no command line arguments. What do you think?

[brliron]

There is just one thing that bothers me with that. If we do that, UTL is thcrap_loader. The user double-clicked on thcrap_loader, so what he runs must be thcrap_loader. Which means we have to change the title bar of UTL from "Universal Thcrap Launcher" (or whatever it has) to "Thcrap Loader". When talking to users, we must not call it UTL, but " thcrap loader GUI". If we do this, we need to present things to the users like that. The fact that we are actually running binaries/utl.exe is an implementation detail.

Another related thought. Remove thcrap_configure from the top-level directory. When you run thcrap_loader for the 1st time, it opens thcrap_configure. If you need to configure again, you open the thcrap_loader GUI, open the thcrap menu, and click on configure. And we make thcrap_loader an hidden file (for compatibility (can we have hidden files in a zip? If we can't, maybe we can use a something.ini system file, or the update mechanism), and replace it with just thcrap.exe.

[lilyremigia]

Here's a something to think about: If we have a setup (or we know that the users will run a specific exe for the first time), if we put anything on the user's desktop and start menu... They will keep using that, and if we go with utl being there only, then anything (including utl) can go into a binaries folder, because normal users wouldn't even look at thcrap's folder unless they want to uninstall it.

[DankRank]

(originally written on June 6th, after Bruno's first message on that day)

I prefer "bin" "config" "logs" "repos".

Rationale for "bin": it's pretty much standard shortening for binaries. It's short and to the point. A tech illiterate wouldn't know what either of "bin" or "binaries" mean anyway. Either of those terms would be equally confusing.

Rationale for "repos": calling it patches would be misleading. In addition, someone might get "patch" and "patch stack" confused and wander into there.

I think I said this before, but why the directory names is the first thing that needs to be dumbed down? I think improving the program UX would give us more benefit, and more importantly, it'd be beneficial for all users. Our directory structure has some flaws right now, and those worsen the UX for everyone (it's a bit hard to find games.js in a directory with 1000+ files). The structural changes have quantifiable benefits, while the name changes do not.

Trying to chase the lowest common denominator is a pointless endeavor. You're always going to find someone dumber. If a user can't click on the only file with a pretty icon in the directory, and instead makes a mess in the bin folder, I doubt they would be able to configure a patch stack, even after all the planned improvements are implemented.

Speaking of configure, I think you shouldn't hide it. Right now it's a piece of garbage, but in 3 days™ it will be a very useful tool that users might want to run more often.

With regard to UTL vs Shortcuts: shortcuts are definitely better for newbies. The main criticism for thcrap always was the complexity (compared to static patches), so shortcuts should remain as an equally supported and recommended alternative.

tl;dr - I want the names to be clean, correct and concise, instead of catering to imaginary group of people for minimal benefits.

[brliron]

why the directory names is the first thing that needs to be dumbed down?

Because using "binaries" instead of "bin" takes about 5 seconds to implement, while for example improving the UI would take much longer. But I can agree with the shorter names.

Rationale for "repos": calling it patches would be misleading. In addition, someone might get "patch" and "patch stack" confused and wander into there.

I agree.

Trying to chase the lowest common denominator is a pointless endeavor. You're always going to find someone dumber. 

I don't think like that. If we make it just a little bit easier to use:

• a few more people will be able to use it;
• the people who were already able to use it but were struggling with it will find it more appealing. Maybe, if the 2nd thing the user sees isn't full of cryptic names, some people will be a little bit less scared, and give it a try it before asking for help? ... or maybe not? I wrote everything above this morning, but after the discussion, I started to think bin may be a better name, because it is more cryptic.

Speaking of configure, I think you shouldn't hide it. Right now it's a piece of garbage, but in 3 days™ it will be a very useful tool that users might want to run more often.

The point wasn't to hide it, rather to provide a single entry point into thcrap. The 1st time you don't have anything so it runs configure automatically, and the 2nd time you can run games so we display UTL, and the configure is just 2 clicks away (thcrap -> run configure). But yeah, how is the user supposed to find the configure the 2nd time? It's no longer where it was... Removing thcrap_configure.exe from the top-level is a bad idea, let's keep 2 top-level binaries.

With regard to UTL vs Shortcuts: shortcuts are definitely better for newbies. The main criticism for thcrap always was the complexity (compared to static patches), so shortcuts should remain as an equally supported and recommended alternative.

Mmh... Yeah, shortcuts are probably more easy to use. So we'll keep them at the top level.

[brliron]

Finished with the 2019-10-05 release