On Sat, Apr 9, 2011 at 4:28 PM, Andreas Stührk <[email protected]> wrote: > > I think the real question is how exactly do you plan to implement the > UI under windows. Basically, bpython needs to be able to jump anywhere > on the screen. At least it needs to be able to reprint older lines > (think of paren highlighting) and it needs some area where it can > display the suggestion window (where the suggestions, the function > signature and the docstring are displayed).
My idea was to start with user input and see what happens when a key is pressed. Then describe the loop of handling the key, creating a list of features (drawing a chain of key processing handlers) on the way. Then estimate limitation of windows console, data that bpython features (handlers) require. Then sort the list of features by complexity and start working on them one by one. So I don't know how to do this yet, but thanks to your feedback I am a few steps closer to my goal. Now I know there is: 1. internal buffer for input (multiline; used for paren highlighting) 2. buffer window 3. suggestion window Is the command prompt a part of current buffer (for code highlighting) or not? I.e. do previous lines participate in rendering line in command prompt? > The basic idea of porting new UIs to bpython is to inherit from > "bpython.repl.Repl" and implement some methods (like "current_line" > that returns the current input line, setting the "cpos" attribute that > indicates where the cursor is positioned etc.). Got it. Seems pretty low level architecture. > That process is not > really documented, please feel free to document it. Who are the right people to annoy with merge requests? bobf federico ikanobori marienz Trundle > Also keep in mind > that the API is really rather line-based and not block-based, ie there > is the current line of input and previous lines never change again. But while previous lines can't change, their visual representation can - is that right? >> I'd like to see UI configurable so that there is a single entrypoint >> in bpython that gives all necessary information about detected UI, >> chosen UI, features enabled, features disabled and the reasons why >> these features disables (TODO or UI limitations). I this could speed >> up porting bpython to other UIs. > > I don't really understand that part. What exactly do you have in mind > and how does it help to speed up porting bpython to other UIs? Sorry if it sounds too abstract. Let me explain why adding new UI to bpython is hard. To add new UI you expect to study how the basic loop/cycle works using minimal example. My case is even worse, because even full example doesn't work failing with with "No module named: _curses" on Windows. To find an entrypoint for further analysis I need to study how curses works, or how GTK works or how urwid+twisted work together. All in theory, because neither UI works on this machine. But there are some things that could help. To implement new UI with zero knowledge of bpython I need to know if the main loop is synchronous - i.e. if after pressing a key the interface doesn't process next key until current one is fully processed. In this case you can expect input lags if processing is too heavy. And if some event handler hangs - the whole application hangs. If the input is asynchronous, then the loop becomes more complicated, but more interactive as you can give priority to keyboard events and resume highlighting when there are no events in stdin queue. For making any changes, it is good to know application components. While there could be separate docs, code is the best documentation, unless it is a dead code. The best way to see if the code is alive is to execute it and follow through the entrypoint. When I executed bpython, I assumed it is a big application and expected it to do several things prior to initialization of UI (yes, I am a naive idealist). Namely detecting available frontends and choosing the default one. But this doesn't work - you have to explicitly run script for your UI. More than that - to find these entrypoints - you need to look through all files in bpython package (urwid interface doesn't have a command line script, for example). However, these scripts don't work from checkout without setting PYTHONPATH properly. For fix this problem I've patched data/* scripts to execute bpython directly from checkout, so you may pull these changes from https://bitbucket.org/techtonik/bpython Ideally I see curses frontend script renamed to `bpython-curses`, and `bpython` becoming a script that runs autodetection steps, lists frontends and can be used to query enabled/disabled (i.e. implemented) features for these frontends. I still don't know if it's possible. > Also, > please understand that we are a little bit sceptical about adding new > UIs to bpython. You're not done with adding the basic functionality, > someone also need to be willing to maintain it. Obviously, we (the > current maintainers, that is) don't have the resources to maintain yet > another UI thingie. No problem. Let's hope it is at least possible to lower the barrier for potential maintainers, and identify main problems that make maintenance hard. If people know what to fix, how to fix and where are major pitfalls, they can contribute more, and you have to spend less. Thanks for the feedback. -- anatoly t. -- You received this message because you are subscribed to the Google Groups "bpython" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/bpython?hl=en.
