[IPython-dev] Curses Frontend Update

Brian Granger ellisonbg@gmail....
Sun Apr 25 23:25:55 CDT 2010


Another thing that should be considered is what the event loops look
like for both curses and urwid.  The reason that I saw this is that I
think it will make the most sense to use 0MQ to get your frontend
talking to ipython.  For that, you will definitely want something of a
real event loop.  If urwid makes that easier then that is worth giving
urwid extra consideration.



On Fri, Apr 23, 2010 at 12:37 AM, Wendell Smith <wackywendell@gmail.com> wrote:
> Hi!
> Yes, you do need to upgrade urwid. I have, which is also the
> latest in pypi, so 'easy_install -U urwid' should do it.
> Secondly, I agree about dropping Urwid. I hate to do it... but, well,
> python 3 support is definitely something I want, and when I asked
> them... they basically said they hadn't thought much about it.
> As for line counts... they are pretty accurate. Both versions come with
> some testing code that is unnecessary ('keytester.py' and
> 'vipadtester.py' in curses, 'palette_test.py' in urwid), but if you
> removed those, the line counts would be even more skewed in favor of
> urwid. As for functionality, they are quite close - except that the
> urwid version handles resizing events just from the library, and the
> curses code looks terrible / would crash after resizing, and I'll need
> to write that.
> So... yes, it would be really nice to use urwid... but I may never be
> able to with python3, so I guess I can't, unfortunately. That's OK, and
> as my curses implementation shows, it may be more difficult with the
> built in curses library, but its definitely possible.
> I still have a long todo list before I start doing any interpreter stuff:
>  - rewrite vipad (in curses - my current implementation is cool, but
> not that useful)
>  - write a nice editbox window (needed for either urwid or curses if we
> want coloring as you type)
>  - get scrolling to work (needed either way, although I believe urwid
> has a widget for that)
>  - allow for resizing (in curses)
>  - handle adjustable-size completions box (done in urwid, not too hard
> in curses once resizing is handled)
> I'm sure there's more... but that's all I've thought of so far.
> Anyways, thanks for the comments!
> -Wendell
> On 04/22/2010 04:58 AM, Fernando Perez wrote:
>> Hi Wendell,
>> On Tue, Apr 20, 2010 at 5:55 AM, Wendell
>> Smith<wackywendell@gmail.com>  wrote:
>>> Hello!
>>> I have been busy coding away, trying to get two prototypes written for
>>> the eventual curses frontend.
>>> They are EXTREMELY basic - they don't even interpret code, just spit it
>>> back out (although in the right place and correctly colored). They are
>>> full of bugs, don't resize well, etc. - but, well, they are prototypes.
>>> What they do:
>>> They both have 3 windows: completions, output, and input. The
>>> completions window shows some default text, the input window accepts
>>> text input, and after hitting enter or<ctrl-g>, the entered code is
>>> highlighted and displayed in the output window.
>>> I wrote these both mainly to compare urwid and curses, which I think
>>> they do fairly well. the urwid library is quite nice, and although
>>> documentation is not perfect, it is good, and the whole thing provides
>>> far more than curses - curses requires you to manually handle resizing,
>>> for example. The code for the urwid part is therefore far simpler, and
>>> was written much faster. It of course requires urwid (easy_install
>>> urwid), and both require pygments (also available with easy_install).
>>> Urwid is much nicer... but development is only semi-active, and they
>>> don't seem at all prepared to port to python3, which is of course
>>> important.
>>> Anyways, please download the code, run the prototypes, tell me what you
>>> think!
>>> Code is on github here:
>>> git://github.com/wackywendell/ipyurwid.git
>>> git://github.com/wackywendell/ipycurses.git
>> Great!  A few comments:
>> - On ubuntu 9.10, I get this for the urwid code:
>> (master)amirbar[ipyurwid]>  python interpreterwidget.py
>> Traceback (most recent call last):
>>    File "interpreterwidget.py", line 112, in<module>
>>      interp = fakeinterpreter(mainwin)
>>    File "interpreterwidget.py", line 81, in __init__
>>      self.formatter = UrwidFormatter(style=s)
>>    File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
>> 29, in __init__
>>      self._setup_styles(colors)
>>    File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
>> 92, in _setup_styles
>>      fgcolstr, bgcolstr, othersettings, colors)
>>    File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
>> 72, in findclosestattr
>>      fg = self.findclosest(fgcolstr, colors)
>>    File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line
>> 54, in findclosest
>>      bestcol = urwid.AttrSpec('h0','default')
>> AttributeError: 'module' object has no attribute 'AttrSpec'
>> I have:
>> In [2]: urwid.__version__
>> Out[2]: ''
>> Do I need a newer urwid to test out?
>> Still, this is a tough one: I am genuinely worried about depending on
>> a possibly undeveloped project. Have you contacted the urwid devs to
>> find out a little bit about future plans/py3 development ideas?
>> Using curses when urwid is around may feel painful, but at this point
>> closing the door on py3k development possibilities sounds a little
>> dangerous for us.  On the other hand, I do see the differences:
>> amirbar[wendell]>  wc -l ipyurwid/*py
>>    117 ipyurwid/interpreterwidget.py
>>    252 ipyurwid/palette_test.py
>>    105 ipyurwid/urwidpygments.py
>>    474 total
>> amirbar[wendell]>  wc -l ipycurses/*py
>>    151 ipycurses/basicsequence.py
>>    142 ipycurses/cursesextras.py
>>     71 ipycurses/cursesparser.py
>>    347 ipycurses/cursespygments.py
>>     32 ipycurses/interpreterwidget.py
>>     11 ipycurses/ipythontest.py
>>     18 ipycurses/keytester.py
>>     57 ipycurses/prototype.py
>>     66 ipycurses/tester.py
>>    241 ipycurses/vipad.py
>>    123 ipycurses/vipadtester.py
>>   1259 total
>> Since I can't run the urwid code right now, how equivalent are the two
>> in terms of functionality? I'm basically trying to gauge if the above
>> line counts can be fairly compared...
>> Cheers,
>> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo

More information about the IPython-dev mailing list