-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Scoop package/cli enhancement #8
Comments
Hey, nice initiative! I feel honored to have my little app featured in a package manager, even if just a personal proxy listing. And good timing too, as I will very soon have a new release which greatly improves several aspects of cmdtab. After reading your enhancement request a couple times, I think I've understood what you want! First let me quickly explain the current state: To avoid having a settings file, on every launch of cmdtab there is a message box asking if you want cmdtab to autorun on login or not. While this message box should show every time you double click and launch cmdtab.exe, it should not show when cmdtab is autorun by Windows on login--that would be weird! So the autorun registry entry uses an undocumented launch argument What you are requesting is a way to launch cmdtab which silently ensures cmdtab is added to the registry for autorun; basically saying yes to the message box, but with no message box. Why exactly you want this I don't understand. But! It nevertheless sounds useful, and I'll add that :) One final note: In the README.md in your underscoop repo you have a typo lightweigth -> lightweight (edit: this typo is also in the JSON). |
I was just trying to look a bit ahead in terms of silent install/setup of the app. And originally I was trying to use the built-in way of creating the registry entry vs using the package manager to handle it. After some thought, I realize that explicitly creating the autorun registry entry during installation (and removing it during uninstallation) is probably a better way of handling this. That is, the package manager can handle those steps in a transparent manner. So I think the way it's set up with the current behavior is fine!. If the package manager were to launch the app after install, it can simply use the So in summary, I don't think my request is super important, but my thought would be that if there is no setting file, and config is done via GUI selections, it would be nice to have a way to do so by arguments as well - but it's not super high priority compared to bugs and usability. But down the line, it might be nice to cover that as it helps those that might want to roll it out to several machines, or otherwise automate the setup. Thanks for pointing out the typo, I will fix that as well. |
Not an issue report, just wanted to let you know that I have created a Scoop manifest for cmdtab. Due to this being a new app, it won't be accepted into the main repos, but I have added it to my personal repo which anyone can use. (If you are not familiar with Scoop, it's a package manager for Windows, similar to Homebrew.)
geekifier/underscoop - scoop bucket
scoop.sh catalog listing for cmdtab
While working on that, I found that there is a need to enhance the CLI functionality just a bit. Mainly, it would be great if there was an
--enable-autorun
argument that could be passed in, allowing for a silent first launch of the app.I considered making a PR, and I had it working where simply launching it with
--autorun
would take care of the registry entries, and launching without (and answering "no") would remove them as usual. However, I am not a C dev and I had to rely heavily on LLM assistance, so I decided against submitting the PR.Also, I believe the way you have planned this behavior out was a bit different, and I did not want to mess with your design.
In any case, thanks so much for writing this, it's such a great little app, and I hope more people find out about it. It makes a huge difference in usability of Windows.
If you are interested, I can write up a quick section for the readme with "Install/Run" instructions, and we could link the package there. If not, take care and thanks once again for sharing this with us!
The text was updated successfully, but these errors were encountered: