• iAmMortos

    I suppose it'd be a nice addition to have some kind of add_path_and_import option as well. I've actually not done programmatic importing before.

    posted in Pythonista read more
  • iAmMortos

    Yeesh, I need to keep a better eye out for emails from this site.

    Once you do the add_path_for, are you performing the actual import for my_cmd?

    import sharedlibs
    sharedlibs.add_path_for('my_cmd')
    import my_cmd
    

    As it works presently, my module doesn't do any importing, it just adds the predefined path in shared_libs.txt

    posted in Pythonista read more
  • iAmMortos

    Oooooh, maaaagic.
    Thank you! This is exactly the kind of improvement I've been looking for!

    posted in Pythonista read more
  • iAmMortos

    Side note, Pythonista has some hooks in Shortcuts as well for kicking off scripts. So even if that's not the best route for this particular project, it's a REALLY powerful tool to keep in your back pocket.
    I have a shortcut called "Burn" that starts a Pythonista script that shows a fire gif and plays a rap air horn... so... lol

    posted in Pythonista read more
  • iAmMortos

    It’s the same as adding a directory to your search path. So nothing is cached or saved or in need of reloading. The only thing that changes is when you add entries to the sharedlibs_list.txt file (which is on my favorites list for easy editing), which doesn’t require anything to be reloaded either since it’s not read until one of the functions in the sharedlibs module is actually invoked. No clutter in the site-packages :)

    posted in Pythonista read more
  • iAmMortos

    Good call. That’s a good fix.

    posted in Pythonista read more
  • iAmMortos

    I found myself regularly wanting to copy modules I had already written into new projects. Things like Dice classes, confirmation views, or even a reusable color picker view. I wasn't about to put everything I thought was useful or reusable in the site-packages. I was aware, however, of the ability to add a directory to the sys.path so I could reference and import it, but in an app on iOS, this full path is very long and gross, and trying to use relative paths instead was almost equally undesirable. And what if the module I made gets renamed or moved? Now all those hard-coded references to its path in other modules need to be found and updated.

    I wrote this little helper module sharedlibs.py to simplify the process and dropped it in the site-packages folder.

    '''
    example use of this module:
    
    import sharedlibs
    sharedlibs.add_path_for('animated_image_view')
    from animated_image_view import AnimatedImageView
    '''
    
    import os
    import sys
    
    
    def get_app_root():
        # Returns the fully-qualified "root" directory of the Pythonista 3 app
        end = 'Pythonista3/Documents'
        cwd = os.getcwd()
        return cwd.split(end)[0] + end
        
    def add_path_for(*modules):
        # Adds the directory for the given library name to the search path so its contents can be imported.
        _libs = _load_libs_dict()
        for module in modules:
            if module in _libs:
                sys.path.append(get_app_root() + _libs[module])
            else:
                raise Exception('No such shared module: .%s' % module)      
            
    # Prints a list of accessible libraries
    def list():
        _libs = _load_libs_dict()
        print('Available Shared Libraries:')
        for key in _libs:
            print('  %s: %s' % (key, _libs[key]))
            
    def _load_libs_dict():
        d = {}
        print(__file__)
        libs_path = '%s/sharedlibs_list.txt' % '/'.join(__file__.split('/')[:-1])
        
        with open(libs_path) as f:
            lines = [l.strip() for l in f.readlines()]
            for line in lines:
                if line != '' and not line.startswith('#'):
                    k,v = line.split('=')
                    d[k] = v
        return d
    
                    
    if __name__ == '__main__':
        # just print the available libraries
        list()
    

    This module and a sharedlibs_list.txt file were both added to the site-packages and nothing else ever again.
    The sharedlibs_list.txt is simply a key-value pair file containing the short names of the libraries mapped to their paths relative to the Pythonista's app root. Something like this:

    animated_image_view=/UI/Views/AnimatedImageView
    brightness=/Utils/ColorBrightness
    config_file=/Utils/ConfigFile
    img_utils=/Utils/ImageUtils
    perm_utils=/Utils/PermutationUtils
    ui_drag=/UI/Draggable
    view_swap=/UI/ViewSwap
    word_utils=/Utils/WordUtils
    

    You'll notice you don't need the full path from your iOS device's actual root; the sharedlibs module treats the Pythonista3/Documents directory as your root since you can't really access much outside there anyway.
    Once Pythonista is restarted, the listed libraries will be accessible via the sharedlibs.add_path_for() function, which will add that library's directory to the search path.

    One single, clean place to define the locations of your reusable libraries for easy import anywhere.

    posted in Pythonista read more
  • iAmMortos

    This is a pattern I've been using to instantiate custom Views that have accompanying pyui files with dynamic data. Just looking for some feedback or any constructive criticism to improve it or maybe just share the pattern if it can help someone else.

    Let's say I have a custom ui.View class called MyView. The pyui file that represents this View would be called my_view.pyui, and would set Custom Class to MyView in the main view properties. This view would contain a single Label component named lbl. I want to be able to instantiate this view with a constructor-like method that affects the contents of the View when it gets shown.

    The following pattern has made this possible in my_view.py:

    # my_view.py
    import ui
    
    class MyView(ui.View):
      def did_load(self):
        self.my_lbl = self['lbl']
    
      def init(self, text):
        '''
        since the ui.load_view() handles instantiating the actual View object, we can't access the true __init__
        method. So we'll call this one as part of our custom static load_view method.'''
        self.my_lbl.text = text
    
      @staticmethod
      def load_view(text):
        '''
        I particularly like this simple shortcut as it allows me to create instances of a custom class somewhere
        else without having to remember the name of its file. Much cleaner.
        This becomes our makeshift "constructor."'''
        v = ui.load_view()
        v.init(text)
        return v
    
    
    if __name__ == '__main__':
      # load MyView and initialize the view's label with text "Hello World!", then show the view.
      v = MyView.load_view("Hello World!")
      v.present()
    

    That wysiwyg UI editor in Pythonista is so stinkin' handy, and this pattern seems like a nice compromise between using the UI editor, and being able to create dynamic, flexible, and reusable views in a pythonic way.

    posted in Pythonista read more
  • iAmMortos

    This I can do! Thanks for the tip!

    posted in Pythonista read more
  • iAmMortos

    Oops. I goofed writing the post. But in my code, I am indeed using ui.CONTENT_SCALE_ASPECT_FILL. I've updated my original post.

    posted in Pythonista read more

Internal error.

Oops! Looks like something went wrong!