[FEATURE REQUEST] Hooks/callbacks into some Pythonista's interface
Phuket2 last edited by
I know this is a low priority at the moment. But just wanted to mention it. I am writing a small script to append the selected text in the editor to a scrapbook file. I have 2 modes. A scrapbook per editor file or a scrapbook per directory.
So all it does, if there is selected text in the editor, it will append something like this to the scrapbook file.
[..ctime() - name of script]
The selected text
It's just often I cut out functions or blocks of code out of my scripts. I want to see that code again the next day or whatever. Maybe I want to copy it and reuse it. But yes, it's just a simple journal or cut history....
I will put the script in the site-packages directory and add it to the wrench
But, it's a 2 step process. . So I have to select the text, then choose the script from the wrench menu , then I have to do the actual cut operation.
@omz, it would be so nice if for these selection menu items, we could define a function that you called prior to calling your action. lets say the function we provide has to return a Boolean. If the function returns False you don't perform the operation, such as a cut, copy etc...A True value, you would proceed as normal. Of course, inside our called function will can implement whatever we want, before returning control. A scrapbook, SQLite journal , etc..
But with this sort of callback/hook system so nice and easy for us to extend Pythonista in more natural way, I think.
Let's say you had a type of property sheet with categories as an interface etc... As time permits, you could add other hooks into Pythonista's functionality . Another example might be 'on new .py' file, it might be possible to return a tuple (proceed, data). The data returned could be inserted into the file. So generically, maybe the return type is always a tuple.
I guess another way, would be just to add a cut selection method to the editor module. But personally, I love the idea of being able to so call hook into Pythonista's actions. Maybe there is a good reason you don't want to do this.
Ok, just my opinion
omz last edited by
I like to be a bit cautious with this type of functionality because it's potentially a pretty big maintenance burden when I make internal changes in the editor etc...
There are already some fun things you can do with
objc_utilthough. As an example, here's a script that appends to a Scrapbook.txt file every time you copy something to the clipboard (with a timestamp). If you'd include this in
pythonista_startup.py, it comes pretty close to built-in functionality.
# coding: utf-8 from objc_util import * def pasteboardChanged_(_self, _cmd, _n): import clipboard from datetime import datetime import editor if editor.get_path().endswith('/Scrapbook.txt'): # Don't add to ScrapBook when copying from it... return timestamp = datetime.strftime(datetime.now(), '%Y-%m-%d - %H:%M') text = clipboard.get() with open('Scrapbook.txt', 'a') as f: f.write('\n\n=== %s\n%s' % (timestamp, text)) try: Observer = ObjCClass('ScrapbookPasteboardObserver') # Observer was already created, don't do anything... except ValueError: NSNotificationCenter = ObjCClass('NSNotificationCenter') UIPasteboard = ObjCClass('UIPasteboard') Observer = create_objc_class('ScrapbookPasteboardObserver', methods=[pasteboardChanged_]) obs = Observer.new() NSNotificationCenter.defaultCenter().addObserver_selector_name_object_(obs, sel('pasteboardChanged:'), 'UIPasteboardChangedNotification', UIPasteboard.generalPasteboard())
Phuket2 last edited by
@omz , I would not have thought editor internal changes would have been the biggest issue. But you are the coder.
However, I can imagine a nightmare supporting people's bad extensions or whatever they should be called.
I am still not even close to understanding Python. But if via asserts or other mechanisms in the language you could be sure of the return types etc.. To make it rock solid... Just saying...
Maybe the mechanism is more like the callback on layout etc...where you have more control. Just thinking out aloud really.
I appreciate what you say about the possibilities with objc_util, but I am more of the school that don't roll your own if you don't have to. it's not about laziness or being scared. Just about conformity.
Really, I like standards , interfaces etc... To write to when possible. Not to say innovation should be frowned upon, but for example you created the dialogs lib for a reason (sorry, have a new topic coming about dialogs), but it promotes a uniformity. A.K.A the first Macintosh toolbox.
But at the end of the day, you know what is best for you and what is manageable, I respect that. I still have to say my little bit though 😘