We have all been hoping that Ole returns to the community at some point and lets us know what the future of Pythonista might be. Unfortunately that hasn't happened so far, but the app continues to function as-is, so we can be thankful for that.

I also prefer Pythonista overall to Pyto, though Pyto continues to improve. The developer of of Pyto, it should be noted, is an 18 year old student, and probably doesn't have a lot of time to interact with the community. I'm not even sure she's aware of the Discord server, but there is a community there, and on GitHub where the source code for Pyto is stored:
https://github.com/ColdGrub1384/Pyto

@JonB @cvp, I have tried a few attempts to contact the couple of support email addresses we have for Pythonista, but there's no response. My guess is it is @omz alone handling anything that comes in there.

Anyway, I think we should continue to work on finding a way to get in contact, though in no way do I wish to put undue pressure on Ole, or come across as pushy or rude. I just want to get a conversation started.

Has anyone tried, or been able to make contact with Mr. Zorn (I think his name is Ole Zorn), the developer of Pythonista?

I wish to respect his right to privacy, and his right not to be bothered by pestering. But I truly wish we had some way of starting a conversation about what the future of Pythonista might be, if any.

It would be such a shame if the app and its community simply died out when either it disappears from the app store, or it ceases to be compatible with a future iOS version (we have continued to be lucky on both fronts so far).

I'm not at all sure how to approach this in a way that is respectful of the developer's situation and needs. Any suggestions welcome, of course.

@mikael yeah, we won't be expecting anything specific from Pythonista development. We'll probably go with something like RabbitMQ which doesn't require any compiled library extensions.

Unfortunately I can't really say anything about what I'm working on here...suffice it to say that we have to rapidly respond to client requests in an environment where development isn't macOS-based, is almost entirely python and c++, but still needed to be able to build interfaces for iOS. Pythonista checked those boxes very nicely.

If @olemoritz is listening, he should know just how good this app is.

@mikael thanks, haven't had much time recently. Rest assured, the pythonista-based stuff I've been building is still going strong. In fact, its inherent stability has impressed everyone.

I did google it, and saw that library...but I'm very very wary of using an old, unsupported thing like that. Was hoping someone here might have a better solution. Perhaps I should ping @olemoritz himself? See if we can get zmq included in the next pythonista release.

I guess what I'm really asking is: is there a pure python client for ZeroMQ so that a pythonista-based app can send and receive messages in a ZeroMQ messaging system?

Since pythonista doesn't come with the zmq library installed, it means there would have to be a pure-python zmq substitute out there? Right? Unless I'm missing something.

Has anyone played around with ZeroMQ via pythonista before?

@mcriley821 yeah, that's what I felt as well...just unfortunate that we don't have a way to access the font descriptors they want us to use instead of names. Well, no way via normal Pythonista python APIs, I'm sure we could do it via objc.

Yeah, that makes sense. I just read a stackoverflow post about something similar to this. This isn't a big deal, overall...I can do something other than setting the widget font to the font of the associated widget.

Does this qualify as a "bug" really? Should the value of the widget.font property be returning something which can't be assigned as a valid value to another widget's font property?

Could someone verify my sanity here...I was noticing some widgets in my UI were getting a different non-system font under Pythonista3.3 on iOS13. And when I investigated, it was only widgets who were setting their font to match another widget.

What I'm seeing is that code like this:

label = ui.Label()
print label.font()
button = ui.Button()
print button.font()
label.font = button.font
print label.font()

will end up with label.font being set to something other than the button's font. It will instead be set to ('TimesNewRomanPSMT', 15.0). In fact, the output is:

('.SFUI-Regular', 17.0)
('.SFUI-Regular', 15.0)
('TimesNewRomanPSMT', 15.0)

Which is decidedly strange. It seems like it actually boils down to that '.SFUI-Regular' font name...it's being turned into 'TimesNewRomanPSMT', and the size comes across appropriately. If I directly assign a specific font, or the special '<system>' value for the font, it works as expected.

Is this some new iOS13 font name that Pythonista doesn't handle properly? Admittedly this is a rare thing to do, setting one widget's font to equal another's...but I was expecting it to work, and it did under Pythonista3.2 and iOS12, and I think it was still working under Pyhtonista3.3 and iOS12.

Sorry for the typos and things...I didn't really test what I posted, just copy pasted stuff from my own project and test code, and modified it to remove extra utilities and things that I wrote which are in other modules.

Thanks to those who fixed those issues, glad it's working.

The ViewHierarchy thing is a utility class I have which holds a bunch of tricks and things for helping with navigating the views in my projects. The actual definition of getUIViewController is:

def getUIViewController(cls, view):
        import objc_util
        UIViewController = objc_util.ObjCClass('UIViewController')
        UIView = objc_util.ObjCClass('UIView')
        if isinstance(view,ui.View):
            viewobj = view.objc_instance
        elif isinstance(view,objc_util.ObjCInstance) and \
                view.isKindOfClass_(UIView):
            viewobj = view
        elif isinstance(view,objc_util.ObjCInstance) and \
                view.isKindOfClass_(UIViewController):
            viewobj = view
        viewResponder = viewobj.nextResponder()
        try:
            while not viewResponder.isKindOfClass_(UIViewController):
                viewResponder = viewResponder.nextResponder()
        except AttributeError:
                return None
        return viewResponder

which crawls the responder chain to find the view controller living above the one controlling the passed-in view, or the view controller if one was given. Anyway...looking at what @stephen posted...I think I should actually just be doing that instead.