-
-
Notifications
You must be signed in to change notification settings - Fork 803
Show already installed package in the "Install Package" panel #1703
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
base: master
Are you sure you want to change the base?
Conversation
Fixes wbond#1569 Users tend to forget what they installed or installed and then disabled. Include in the "Install Package" panel all these packages as well. For the disabled packages, rewrite the action and just enable the package.
3de40ba to
2c5d20b
Compare
|
"Bracket Color Scheme" is not disabled in your case, or is it? I think the code is straight forward and correct in what it considers to be disabled. |
|
No it's not disabled, but I wouldn't expect it to re-install a very well working package in that case. |
|
Yes, better don't hit But then I thought: okay people are maybe searching for packages that they don't think they have already installed because they actually don't work. I get regular user reports that users just re-install packages if they don't work. That's where this decision comes from. It is still an action panel. I do like davids mockup he showed on discord. He also provided a "reinstall package" for installed packages but then some more. IIRC for installed packages it open a next panel with reinstall, uninstall, show homepage, show readme or so. But that's a whole other level. |
|
The issue is it beeing very/too subtile. I haven't touched those quick panels in 4.0 because I didn't want to add too many multiple code paths to maintain compat with old ST3 and current ST4. Basically, I think we should somehow prepare a 5.x version, which drops support for python 3.3 and ST3 at least, so we can switch to more modern programming paradigms, libraries etc. This would then be the step to refactor various of those front-end functions as we can then rely on things like What I have in mind is to use kind info to display state of packages. Maybe green check boxes for installed and active packages, grey ones for disabled ones and a download icon for those not yet installed - for instance. Someone recently even made a suggestion (on Discord?) with a quick panel / InputHandler? leveraging all operations for packages. I'd in general switch to input handlers then. One panel which contains all packages. When hitting enter on a selected package open another input handler with available operations (enable/disable/upgrade/remove/install), maybe. Needs some case study to find best solution. Hence I hesitate to change too much in current major release, TBH. I already skipped this issue for those reasons after thinking about it back in the days when working on initial 4.0 |
|
This is just a baby-step again and basically in style of what we already have. To get it "right" in one step is basically too much to ask if everything at every edge is on fire. Remembers me when I took GitSavvy (and you made a simple PR how to optimize the find_git_root thing -- took me a year to actually implement this), everything was just loosely working, and every commit had a "but..." somewhere. I didn't even know that we still ship new versions to ST3 because there is ".python-version" at the root that misguided me. (I thought parts of the software were copied to the py33 host on the fly.) Why is that? Sure ST3 people get any updates from the channel.json, but they can't expect new versions of PC! (?) (The plan for -- or: the ability of: -- the "new crawler" was to write st3 and st4 channels separately, we already save 1MB for the st4 channel, and the st3 channel might save too or naturally dies and turns into a static asset over time. Me:
You:
That should be the same thing. We should just ask him for the code. Or maybe that is an aspect you really like to program in Sublime Text -- (I don't - I esp. hate the design aspect of it.) That being said switching off py33 is not a major step. Nothing changes for the ST3 users and nothing changes for the ST4 users. (I never do a major when switching off an old python version.) We can just make it, freeze a st3-4.0.9 and then do the other baby-steps. Obviously, wbond is not here so we do need an override of Package Control in the main registry (p_c_channel) because that is registered in wbond private repo. 🙄 |

Fixes #1569
Users tend to forget what they installed or installed and then disabled.
Include in the "Install Package" panel all these packages as well. For the disabled packages, rewrite the action and just enable the package.