headers
Kirk McDonald | 2 May 2010 23:55
Picon

Urwid for Python 3

I have ported Urwid to Python 3. The unit tests pass, and all of the example scripts work. It may be found here:


http://bitbucket.org/kirkmcdonald/urwid-py3k/

There are caveats:

The curses back-end does not work. The semantics of the curses module are slightly different in Python 3, and I have not bothered to work around these changes, yet. Specifically, the Python 3 version of curses wants to operate on Unicode strings, and it insists on encoding these strings in UTF-8. Therefore, the curses back-end could be made to work as long as the current encoding actually is UTF-8, but I have not yet bothered to fix it.

I have not tested either of the GLib or the Twisted event loops. (I don't even think either of these libraries have Python 3 versions.) I flagged the relevant doctests with "+SKIP".
_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Permalink | Reply | 1 comment |
headers
Ian Ward | 4 May 2010 02:10
Favicon
Gravatar

Re: TreeWidget/TreeWalker class

Rob Lanphier wrote on 2010-04-04 23:43:
> On Sun, Apr 4, 2010 at 7:32 AM, Ian Ward <ian <at> excess.org> wrote:
>> Rob Lanphier wrote on 2010-03-24 03:06:
>>> Let me know if/when you'd like me to prepare [treetools] for inclusion into urwid
>>> mainline.[...]
>>
>> I believe I made some whitespace changes browse.py that clutter the diff
>>  to your version.  Would you merge those changes or prepare a patch
>> against the latest version of browse.py?
> 
> Done.  Here's the branch that I did the integration on:
> http://bitbucket.org/robla/urwid/

I've pulled your changes and spent some time working on that code.

I'm still not 100% happy with the interface: it should be possible to
put any kind of widget in the tree, not just text.  But, it's getting close.

I think I will start expanding the tutorial based on an improved browse
example, split into a bunch of incremental improvements.  It would be a
good base to show how to use a worker thread, how to not consume an
unbounded amount of memory in widgets and a few other useful things.

Ian
Permalink | Reply | 1 comment |
headers
Ian Ward | 4 May 2010 03:20
Favicon
Gravatar

Re: Generic dialog popup implementation...

Arcadie Cracan wrote on 2010-01-30 09:36:
>>
>> Finally it would also be better to separate the loop handling from the
>> dialog itself and make the dialog just another widget.  I'll post again
>> when I have time to update the example to do this.
>>
> 
> Done (sort of...). Look at the implementation of DialogDisplay.show(). The 
> dialog now raises 2 kinds of exceptions: ChildDialogExit and MainDialogExit. 
> If a ChildDialogExit is encountered, then the loop is "re-run" (is it correct 
> to do this?).

I think we need to keep the loop in the user's code somehow.  Twisted
has a way of passing in a generator that yeilds deferred objects when it
needs to wait, instead of writing a bunch of tiny functions that call
back to each other.  I think we could do something similar with Urwid.

Something like:

    def conversation_app(loop):
        # initialize the display
        create_conversation_widgets(loop)
        # allow the user to introduce themselves
        # and wait for them to click OK
        dialog = ask_name_dialog(loop)
        yield dialog

        # if they gave a name, greet them
        if dialog.name:
            yield say_hello_user_dialog(loop, dialog.name)

Does this kind of interface make sense?  I'm open to suggestions.

Ian
Permalink | Reply | 0 comments |
headers
Ian Ward | 4 May 2010 04:11
Favicon
Gravatar

Re: Demo code

Rob Lanphier wrote on 2010-04-24 03:29:
> I probably won't be able to incorporate feedback before Sunday, but I'd
> still like your thoughts because I'm probably also going to use this at
> OSCON in July.

It looks like a great introduction, Rob.

I've used github to make minor comments:
http://github.com/robla/urwid-demo/comments

I think your closures are the simplest way to do what you're trying to
with the the FieldManager class.

It would be great to have as part of the documentation, maybe as a
screencast?

Ian
Permalink | Reply | 1 comment |
headers
Rob Lanphier | 4 May 2010 06:41
Picon
Favicon
Gravatar

Re: TreeWidget/TreeWalker class

On Mon, May 3, 2010 at 5:10 PM, Ian Ward <ian <at> excess.org> wrote:

Rob Lanphier wrote on 2010-04-04 23:43:
> Done.  Here's the branch that I did the integration on:
> http://bitbucket.org/robla/urwid/

I've pulled your changes and spent some time working on that code.

I'm still not 100% happy with the interface: it should be possible to
put any kind of widget in the tree, not just text.  But, it's getting close.


Cool, I'm looking forward to seeing what you come up with.  I'm assuming you're referring to the interior/parent tree nodes when talking about the widget types...that's one area I didn't put a lot of thought into generalizing.  The leaf nodes can have different widget types (I'm using several different types in jsonwidget).


I think I will start expanding the tutorial based on an improved browse
example, split into a bunch of incremental improvements.  It would be a
good base to show how to use a worker thread, how to not consume an
unbounded amount of memory in widgets and a few other useful things.


I can see that.  It took me quite a while to get my head around that example, so having an incremental approach would be really useful.

Rob

_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Permalink | Reply | 0 comments |
headers
Rob Lanphier | 4 May 2010 06:51
Picon
Favicon
Gravatar

Re: Demo code

On Mon, May 3, 2010 at 7:11 PM, Ian Ward <ian <at> excess.org> wrote:
Rob Lanphier wrote on 2010-04-24 03:29:
> I probably won't be able to incorporate feedback before Sunday, but I'd
> still like your thoughts because I'm probably also going to use this at
> OSCON in July.

It looks like a great introduction, Rob.

I've used github to make minor comments:
http://github.com/robla/urwid-demo/comments


Excellent!  I'll probably do another rev of the examples before July, reordering some stuff.  Thanks for the really detailed feedback!


I think your closures are the simplest way to do what you're trying to
with the the FieldManager class.


Yeah, I think once the checkbox sneaks in there, then having a generic, widget-independent way of getting the data means having a closure.  One thing that occurred to me which I might implement in one of the beginning revisions is a really simple loop though all of the fields calling get_edit_text() on each.  Since the early revisions only have text-entry, I can get away with that, and then introduce the FieldManager concept at the same point I add the checkbox.

 
It would be great to have as part of the documentation, maybe as a
screencast?


Sure, I was dabbling with the idea.  I'm about to start a non-urwid related contract job, so I'll probably have less time to devote to this stuff, but I should be able to crank something out one of these weekends.

Rob

_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Permalink | Reply | 0 comments |
headers
Visgean Skeloru | 4 May 2010 15:01
Picon
Gravatar

TypeError: 'Text' object is not iterable

Hello, I wrote this code: http://gist.github.com/389121 , but it´s returning me this error: http://gist.github.com/389374 , as you can see from this code: http://gist.github.com/389123 the problem isn´t in self.paths... Do you know where problem could be?

_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Permalink | Reply | 2 comments |
headers
Ian Ward | 4 May 2010 15:04
Favicon
Gravatar

Re: TypeError: 'Text' object is not iterable

Visgean Skeloru wrote on 2010-05-04 09:01:
> Hello, I wrote this code: http://gist.github.com/389121 , but it´s
> returning me this error: http://gist.github.com/389374 , as you can see
> from this code: http://gist.github.com/389123 the problem isn´t in
> self.paths... Do you know where problem could be?
> 
> 
> 
> _______________________________________________
> Urwid mailing list
> Urwid <at> lists.excess.org
> http://lists.excess.org/mailman/listinfo/urwid

Your _get_at_pos needs to always return a position and a widget.  The
last else: only returns a widget.

Ian

_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Permalink | Reply | 1 comment |
headers
Visgean Skeloru | 4 May 2010 16:51
Picon
Gravatar

Re: TypeError: 'Text' object is not iterable

2010/5/4 Ian Ward <ian <at> excess.org>
Visgean Skeloru wrote on 2010-05-04 09:01:
> Hello, I wrote this code: http://gist.github.com/389121 , but it´s
> returning me this error: http://gist.github.com/389374 , as you can see
> from this code: http://gist.github.com/389123 the problem isn´t in
> self.paths... Do you know where problem could be?
>
>
>
> _______________________________________________
> Urwid mailing list
> Urwid <at> lists.excess.org
> http://lists.excess.org/mailman/listinfo/urwid

Your _get_at_pos needs to always return a position and a widget.  The
last else: only returns a widget.

Ian
 
oh, it works, thank you. 
_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Permalink | Reply | 0 comments |
headers
Ian Ward | 4 May 2010 23:35
Favicon
Gravatar

Re: Urwid for Python 3

Kirk McDonald wrote on 2010-05-02 17:55:
> I have ported Urwid to Python 3. The unit tests pass, and all of the
> example scripts work. It may be found here:
> 
> http://bitbucket.org/kirkmcdonald/urwid-py3k/

That's great Kirk!  Python 3 support will be a big deal for the next
release.

It looks like many of the changes are compatible with 2.x.  I'd like to
separate out and include those changes in the default branch.  I'm
planning to drop 2.3 support if that makes things any easier.   Also
some of the changes can be left to the 2to3.py script.

I'd like to get the core of this patch set down as small as possible,
something that can be applied either before or after the 2to3.py script
is run.  If it can be applied before then the changes could live as a
branch in the main repository (nicer for ongoing merging) along with the
script to run to complete the conversion.

You've done lots of work already, so if you're not interested in the
remaining clean up that's fine -- I'll get to it eventually.

Ian
Permalink | Reply | 0 comments |

Gmane