Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
Black Mamba - open quickly and other shortcuts
-
@JonB first issue (Pythonista version) fixed in the
master
(not released yet). Second one (shortcuts) is in the category no need to do anything. I just tested it ...keyCommands
method is called zillion times and it must be blazingly fast. So, I'm just concatenating two lists. Just tried to filter BM key commands there and experienced significant slow down of Pythonista. Almost unusable even on the latest and biggest iPad available. No way to do it here. Slow down wasn't here just because of filtering only, but some print statements, ... -> no way.Issue is that I have no idea what key commands Pythonista provides, because original
keyCommands
does return different set of shortcuts. Depends on where I am (what's open in Pythonista). I can't filter out key commands in advance -> no way.Anyway, I just tried to assign same shortcut for one of my commands to test what will happen. Found that the first command in the array is used by the iOS - HUD, functionality, ... In other words, when Black Mamba registers command with some shortcut which is already provided by the Pythonista, Pythonista one will be used automatically, because I'm concatenating Black Mamba key commands at the end of the key commands list.
-
@zrzka Seems like it should be possible to call keyCommands in advance (at startup), for a few of the main viewControllers, to see what is provided. IIRCthe little keycommand swizzle technique we have been using swizzles the root view controller, so it is last in line. It would technically be possible to swizzle down at a particular view controller, say, to have commands in the editor, and different commands in the console.
But, point taken, that if ole changes the structure of the app, then things break if you are trying to be too clever. -
@JonB that's what I initially did want to achieve with scope (removed) - to have different set of shortcuts for the editor, console, ... I will eventually put it back, because we have lot of commands now and I'm accidentally closing editor files when I hit Cmd W in the console for example :)
-
@zrzka, I am not sure if you use the ui Designer or not. But a great addition would be if you were able to inc/decrement the x,y position fields and the width, height fields with the arrow keys or shifted combo of these keys. (I guess the trick, maybe doing that without changing the focus).
This could give keyboard positioning and sizing of objects in the ui Designer. Another nice addition would be a object cycling selection key like tab for example.
Sometimes i can be quite hard to select an object without resizing or moving it.Look I understand this may be way outside the scope of what you want to do. And it may not even be possible. But thought it was worth a mention. Never know unless you ask
-
@Phuket2 thanks for the suggestion. I was thinking about this as well and decided not to do it. Not that it's not possible, but it will use lot of Pythonista internals and even a minimal change from Ole can break it. Thus it will lead to maintenance hell.
Yes, I do use it and to be honest, it's a tough job sometimes. I'm talking about complicated UI. If it's simple, designer works perfectly. Agree it would be super useful to use [Shift] Tab for cycling and arrow keys for x, y and shift arrow keys for width, height. Also backspace to delete selected item.
Anyway, you should fill issues for all these ideas, so, that @omz will not miss them and they'll be eventually implemented.
-
@zrzka , thanks for the answer. I have posted these as issues on github recently. But i understand, for sure this better implemented by @omz. Not that i could do it myself, but I can imagine it could be quite brittle. I think @omz will address it. I am sure It's just about priorities.
Again thanks for getting back to me -
@zrzka, this maybe a crap suggestion but i am going to suggest it anyway :) What about a dedicated key combo for BM version check with an option to run the requests update script. It seems to make sense to me at least for now giving you are updating regularly. At first I was thinking about something in the startup script. I would not have a problem with that, but I think maybe others would. Anyway, food for thought.
Btw, i changed to using the requests install script. It did fix some problems i was having using the git pull. Same version. So seems to me that the git pull idea is dead.
-
@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 blackmamba
to 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.
-
@Phuket2
pip
fixes were merged todev
. If you'd like to test it, you can use StaShdev
branch ...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
pip
will be stable enough, will work as expected, will be merged tomaster
, I'll switch Black Mamba topip
only. Now I'm releasing it to PyPI as well to testpip
changes. -
@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:
blackmamba.log.*
blackmamba.key_command.register_key_command.*
&UI*
constantsblackmamba.main
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
update.enabled
) - Registers default keys (can be disabled via
general.register_key_commands
)
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 useregister_key_command
. The only thing which is missing isunregister_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.