Black Mamba - open quickly and other shortcuts
@Phuket2 I decided to fix pip (here's the pull request) instead of reinventing wheel with installer, updater, ... So, when the PR will be merged and it will be available in the next StaSh version, I'll switch the installation method back to pip and will trash the current installer.
Then I'll update check for updates method to check against PyPI. If there will be new version available, I'll copy
pip update blackmambato the clipboard and will inform you about this in an alert. So, decided to fix the root cause (pip), not the workarounds :)
@zrzka , sounds good. I didn't really know about the pip update problem until recently. It's great its getting fixed. Being a novice, I thought I was doing something wrong. Appears to do the remove ok, just not the new install :)
I often run selfupdate in StaSh, so should see when it comes through
@Phuket2 pip was broken in several ways ...
- Uses XML-RPC which is legacy API and it causes issue that newly released versions are not returned, you have to wait more than 24h and sometimes even longer.
- pip update internally calls install, but ...
- invalid version specifier arguments passed -> exception
- pip install command is wrapped with fake setuptools modules, ... but update isn't and because update calls install, it doesn't work
... fixed these things, tested and it works for me. Hope someone will find time to review, merge and release it.
pipfixes were merged to
dev. If you'd like to test it, you can use StaSh
selfupdate -f dev
... then restart Pythonista (to reload StaSh), then ...
rm -rf ~/Documents/site-packages-3/blackmamba pip install blackmamba -d ~/Documents/site-packages-3
... restart Pythonista (to reload Black Mamba).
And now, whenever you see new new post in Black Mamba - releases topic, you can update Black Mamba via ...
pip update blackmamba
... that's it. If
pipwill be stable enough, will work as expected, will be merged to
master, I'll switch Black Mamba to
piponly. Now I'm releasing it to PyPI as well to test
@zrzka, I had some ideas about BlackMamba today. I cant keep up with all the thread items so this may have been discussed or somewhere in your vision.
I noted the other day you mentioned about your vision for BM being more than just a KeyMapper, or words to that effect. You can see that by the helpers you also include I.e ''open quickly".
I was thinking today, what If I wrote a calendar app (for example). Let's say I also wanted to support a set of keyboard shortcuts, like 'go to today, 'go to next/previous month' etc. You get my drift. Seems like it would be great if somewhere in my app startup code I could import bm, start it. Then when loading a view to be able to make the calls I need to do the keymapping (preferably some container that could be passed as a set of mappings). Then when view is closed make the required calls to unregister the mapping set. Possiblly a global set could be created/registered on the app startup, and the contextual views done as said above.
Of course all the key mappings need to be backed up with ui Equivalents. You could leave this to the developer to figure out, or have a few helper Libs to create for example a popover view , that links into the registering of the keymappings.
Another bonus would be that any keymappings that get registered during the apps lifecycle are automatically unregistered when the app terminates. Just to save ourselves from ourselves :)
It would be nice if the user didn't have to run BM as it stands today. Meaning they could opt to just to import it and use its keymappings and other tools that you could/would expose that may make sense in their app as you would use any other lib. The fact BlackMamba is on PyPI also fits in nicely with this idea.
It seems to me you have either most or all the working parts their now. Then again, maybe I am trivialising some of aspects of doing this on the fly and having potentially multiple contexts running at one time. I mean, if you where running your app presented as a 'popover' in the wrench menu, or as a panel for example.
Anyway, not sure what you think. Look BM is super useful already. To me this is way you could extend its use to benefit even people. Anyway food for thought. I had some other ideas also. I put in another post later.
@Phuket2 thanks for your input.
What's the main goal of Black Mamba? Basically there're two:
- make great IDE from Pythonista (it's "just script editor" from this point of view today),
- make experiments Ole can't do, show Ole what we miss and hopefully some of these things will be added to Pythonista some day. If not, can still live in Black Mamba,
- provide functionality for both external keyboard and tapping users.
What's the current status?
Still alpha, still lot of breaking changes inside, ... From this point of view it's not a good idea to allow others to use internals. It will mean that I have to maintain compatibility and that's not what I want to do now. I do maintain stable "API" in:
And that's it. Also some of the Black Mamba features were wrapped with scripts usable as actions (= wrench icon) if you don't have external keyboard. That's also the main reason why I put back title bar with X button instead of my custom title to allow non keyboard users to close these dialogs. These last two changes were not officially released yet (not fully tested).
How the 1.0 can look like?
Black Mamba in several packages. One for UI stuff, one for runtime stuff, ... and one which does use all these packages to provide IDE functionality. Then, we can start talking about exposing some of these features via stable API to others. Like key commands registration / deregistration, ...But it's too soon to do it now. Latest release is 0.0.24, still a long way to 1.0. I'm alone, have job, ... and I have to minimise amount of work. That's the main reason why I'm not willing to maintain wider stable API except mentioned ones. So yes, I was thinking about this as well, but my time is kinda limited.
Not recommended part
Anyway, what main does?
- Updates config
- Checks for updates (can be disabled via
- Registers default keys (can be disabled via
See default values. Basically, if you do not want to call
main, you're not forced to do it if you're not interested in updates, default shortcuts and if you're happy with default config. Then feel free to use
register_key_command. The only thing which is missing is
unregister_key_command. If you want it, file an issue.
Or you can use register_key_event_handler / unregister_key_event_handler in your dialogs. See this as an example how to use them. BUT, as I said, it's not officially supported. Can break any time (not likely), but can. I warned you :)
@zrzka, thanks for the reply. I understand your rationale.
Sneak peak of new features that are coming ...
... 1.4 will be focused on refactoring. Another feature will be import organization (sorting, ...).
@zrzka , if you ever get bored one day, a nice challenge for you might be a search view like the latest version of the working copy app does. I think its so well done. I thought of you and BM when I seen it in action.
Maybe another dev here might aklso be interested in doing something like that also.
@Phuket2 thanks for the idea. It's already reported as #21, but I'm not still sure if I should do this. Basically I don't need it, I'm happy with jump to definition, find usages and other stuff. Full text search can be slow, because you have to check all files again and again, or you have to store some indexes, then you have to validate them, check if something were changed, ... I'm not going to do this probably. Sorry :) As I wrote, focusing on refactoring, that's what I miss now.
@zrzka , no problems. I understand. Can't blame a guy for pushing his own agenda :). But anyway, it is a cool search implementation. In 20 years or so when I get better, I might attempt it :).
LOl, you can see I was also able to slip in another plug for Tinydb. I am shamless :)
It would be cool if you could add the futurize process (at least steps 0 and 1) which is a much more modern, less distructive approach to the 2to3 conversion that is built into Pythonista.