Major changes, cosmetic and functional, NO API KEY METHOD, NO SETUP #99
Conversation
firepacket
commented
Jan 18, 2022
•
firepacket
commented
- Single EXE
- Portable Executable
- No extra files
- Fully Localized Internally
- Fallback No API Key Required! (Better with API Key)
- No Setup
- Right-Click Context Menu Support!
- One click uninstall
- All new strings localized and missing localized strings added
…Settings Completely fixed all issues I found with this project. Cleaned up a lot of files. This is only a single .exe that gets installed via Settings. I put the localization json in a dictionary. No API key uses different method which still works instead. Using Built-in Settings now.
more info better description
|
Failing check can be fixed by simply Package-Install Costura.Fody It is included in base directory. This keeps everything in 1 .exe with no setup. |
firepacket
changed the title
Would be better to use ILMerge if you insist on having single executable for some reason.
That... breaks the purpose? The localization files are separate for a reason. So that people can easily create them without having to do any changes what so ever to the actual program or even recompiling it.
Bundling old version of the official VT uploader that is being extracted and used when no API key is present is just... weird way to do it? Of course it does not require API key since it has one bundled in. Please refer to #87. Also bundling any executable like so is a bad practice and not something that will ever get merged.
How is that an advantage? Many people would like to use it repeatedly and having it conveniently installed in the system (and not just exe being in some random folder) it the preferred way.
Setup (and uninstaller) adds VT to context menu. Having the actual program do it is also a bad practice. If you remove the exe (since it would be supposed to be portable?), you would then have to manually delete the context menu entry. Not everyone will be aware of that. Having an uninstaller that just removes the program as well as the context menu entry is what people expect and what they are used to.
As mentioned above, if the installation method is to just drop the exe to random folder, then the expected uninstallation procedure is to just remove it. I don't want people to complain about an invalid context menu entry. I know that some people would understand how this works, but from experience (if was in older versions like that, before recode) some people don't and I don't want to deal with it.
I do agree some strings are missing localization. Will try to fix. |
|
Oh well. We have different design philosophies.
Fody is easier.
What end user is going to spend time translating everything with json? There was no functionality to even do that properly. The dev always does copy/paste translate.
Yep I bundled a small app that has functionality your software was missing. I got the job done. Which version works better?
I clearly say Settings -> Reset to uninstall. You think your users are that dumb they can't click a single button and navigate a settings dialog, but can localize with .json files themselves? Double standard. I am much happier with the software after my modifications. I absolutely hate installing and uninstalling small apps. |
Depends. Probably subjective.
Simplifies push requests. You can upload the file through the GitHub's web interface or mail it to me (which few people did).
Out of date app which uses old deprecated API, is being self-extracted by another - non installer - executable (which can ironically trigger antivirus protection and smart screen filter) and it does not have the source provided (or linked) in the repo. Even if we ignore all of that, then why: a.) If the source code of it is available then why not to just port the code for it
We are talking about push requests. JSON is quite easily understandable by the users while going into the actual C# code and trying to figure out how to add the translation might scare away people. If you really want to bundle it in, then don't hardcode it, but make it the apps resource at compile time. As I said in the previous comment, there had been a button in the settings to add the context menu before recode. People would remove the exe and then they would be surprised that the context menu is still there. Maybe I just got unlucky and it was some sort of meeting of people without basic technical skills or reading skills because it was written everywhere that you have to remove it, either way I don't want such situation to repeat.
To finish things off, I respect that you have your own opinion on how it should work and that you have forked it and made it your own. That's why it's open source after all. The fact that you hate installing programs though does not mean that everyone else does. Furthermore, Windows 11 changed the way context menu entries can be registered. You can not longer just write your own entries into registry so in order to make it work properly on 11, I might have to move the whole project into UWP (which guess what, won't run without install at all - although I can put it in MS store I guess). |
Just put the Dictionary in it's own file and people can still add their json and language. WHY FAVOR SPRAWLING FILE STRUCTURES? You're abusing the filesystem. Localization can all fit in one file.
Pedantic much? I solved this problem fast in a nice clean way. It was what I was using before anyway, so it made sense for me to make it a fallback if something happened to the API key. I could have reversed engineered it, but that leaves less time for the other features I cared about. I was already using it! I code for ME not for PEDANTICS. You're making excuses based on excessive pedantry. Your own app could be blocked by smartscreen. Just make a cool app that people like to use.
Like I said, just move it into a single file. It's still JSON. Don't abuse the filesystem. Put it into a single .cs partial class they can download it add their JSON and upload it back. It just takes a few minutes to add an entire language with a decent text editor and Google translate. Actually if you really want to solve this problem, use the builtin Properties.Resources like I did with Properties.Settings and have a button open the file for editing.
So some people are idiots. There will always be idiots no matter what you do. People don't know how to follow directions? It's right there in the Readme. Besides, if they forget they could just re-download it, go into Settings, and hit Reset. Gone. No stressing.
I bet people would like not worrying about an API key. It's 2 apps in one! Small files like this DO NOT NEED TO BE INSTALLED. You only install things that make massive changes to your system. This app should be portable and I think most would agree.
They are throwing out the registry? No. There will always be a way to register a context items in the registry, setup or not. UWP sucks, the MS store is for little kids. Yeah, give Microsoft full control over your app. From the link you sent me:
You know Windows was BETTER before they started copying Apple. Maybe you should go back and see how it actually worked. It was pretty cool. Apple is just BSD. Windows is unique and very powerful if you understand the lower levels. |
|
I have better things to do then do write back and forth with you, so I am going to react just to the few last things.
I don't want to be rude, but unless I am missing something then it's fair to say that I do understand Windows on lower level pretty well and probably much better than you do.
Cool? And what am I supposed to do with it? Like it or not Windows 11 is now the latest version of Windows and will come preinstalled on new machines. If it does not work properly on latest Windows release than it means it's outdated. |
Resist. I am. There are enterprises using Windows who don't want that kiddie crap pushed on them. There are Windows Servers that have been in use for years. The base Windows will not go away it has just as much history as *NIX, and it just might make a comeback if you ignore all this other Apple garbage they are pushing on us. EDIT: BTW cool projects! |
