Provide support for other scheduling models about asciimatics

[peterbrittain]

OK - I've now added the other half with 5356447

It works well enough for me... Can you please let me know whether it works for you and then I'll close this enhancement.

I'm very glad to see this enhancement in your issue tracker and would like to say I would appreciate this feature greatly. I was checking out asciimatics and was hoping to use it with/integrate it into my framework. Right now, it appears that calling Screen.wrapper does not return a screen object, but simply starts it's own event loop.

This basically prevents me from using asciimatics concurrently with my framework, without resorting to icky workarounds like parallel threading. Since it looks like that is the only way to have the two play together, it basically means I can't use your package to provide a frontend for my apps at all, which is a shame, as that would be pretty awesome.

[peterbrittain]

The exact interface here might be interesting. Screen.wrapper() does not actually start the event loop. It is similar to curses.wrapper() in that it notes down the current environment, sets up what it needs and returns the Screen object through the function specified as a parameter to the wrapper() function, then tidies up the environment when that function returns.

I guess these days, there might be a case for doing this within a context manager, but that still doesn't solve the scheduling issue.

I would expect applications that want more control on the scheduling to need a method (let's call it Screen.next_frame()) that allows them to handle any input and draw the next frame of the Scene. In other words provide a single iteration of what is happening inside Screen.play(). This can then be called at a convenient point inside your main loop.

Actually, I played with it some more, and figured out a way to get it to work. Screen.wrapper might return None, but I can save the screen as an attribute of a object using the method that wrapper() requires. Then I can use that to get keypresses. Here's how it looks, if you were curious: https://github.com/erose1337/pride/blob/master/asciitest.py

Looking forward to using the rest of it!

[peterbrittain]

The way you let wrapper return means that the program will not reset correctly once you have finished. You'd be better off simply wrapping your existing main function to be called by wrapper. It also may result in bad output as it will be using the wrong win32 handles in this case.

I suppose that's why I was having difficulty getting the screen to refresh. I'm going to have to play with it a little more.

Currently, I have my own Command Line object that retrieves user input and handles output of it, albeit in a manner significantly less spectacular then asciimatics. This object appears to be more or less equivalent to your Screen, in that it processes the input/output. The way my framework functions, the Command Line is only created for some programs, and not for others, depending on the nature of the program and if it is required. The normal entry point for creating a terminal is when a User is created, which is potentially an instruction that can be executed at any time, not just when the program is first launched..

Is it possible to separate Screen creation, Screen running (i.e. getting input, refresh), and resource cleanup into separate methods? If it's already this way, what functions should I use for each purpose?

If you're taking suggestions for an interface, I would vote for:

• Create a screen object
  • Allocates resources and whatnot
  • Does not process any input/output
  • Returns the Screen object
• A run method for the screen
  • Overload to do input handling/display updating/refreshing
  • Can be scheduled by the framework to run every X seconds
  • Does not deallocate/cleanup anything when function exits
• A finalizer method
  • Cleanup/restore any required resources

Thanks for all your help!

[peterbrittain]

Just a sec...

If you have an entry point in your application where you want to call a function to handle your User interactions, why don't you just call that entry point with Screen.wrapper() instead? Once your code exits (presumably when the User session is over), the function will return and so the wrapper will tidy up and also return...

Or is your application asynchronous, and so you need your Screen to be created in a completely different function from where it will be tidied up?

My application is asynchronous, and I do require that it is cleaned up in a different function from the one that it is created in. You hit the nail on the head there.

As an explanation, my application uses well known names/references to objects. These references can be looked up in a dictionary to return the object indicated by the reference. This results in a different information flow. Objects are created, and may exist for the duration of the application, or be deleted at arbitrary points during execution. Many objects exist as part of the environment, providing commonly required services. It is reminiscent of dbus, if you are familiar with that.

This lets me easily create programs that function concurrently with any other ones I have written, and most enjoyably lets me do so with no weird headache material like threads/locks/semaphores/stack frame switches/eventlets/asyncio/yield/etc. It also provides me with a command line I can use to investigate the state of my programs while they are running. I have many objects/daemons that use this interface already, so I am pretty much married to it.

[peterbrittain]

I've now written the first half of this with 9450f60

This introduces the open/close functions on Screen so you can create a Screen and tidy up whenever you want (and now make wrapper use these). Need to break apart play next.

Awesome, I'm excited! Thank you for responding to my feature request so quickly. Hopefully any changes weren't too painful on your end?

It is working beautifully. Thank you so much!

[peterbrittain]

Great! And you're welcome.