Goffi | 2 Oct 2011 23:28

Urwid 1.0.0: it seems broken

G'day,

first congrats for this 1.0.0 release, it's always something special for 
a project :).

Unfortunately, I have bad news: after somebody used my XMPP client (with 
a console frontend based on Urwid) he contacted me because of crashes.
I saw he was using the new version, so I upgraded, and realized that my 
frontend (primitivus, see http://wiki.goffi.org/wiki/Salut_%C3%A0_Toi if 
you want the sources) is broken with this version.

I haven't tracked everything yet, but

- the method is_mouse_press is not available any more. After quickly 
watching the sources, it seems to be now in urwid.util , but I see no 
mention of that in the CHANGELOG.

- I have crashed in my app when I pressed an unicode key (like the 
french "é"). I quickly looked the code and saw in widget.py, line 983 
and beyong:

   tu = isinstance(text, unicode)
   [...]
   if tu:
       return text.encode('ascii') # follow python2's implicit 
conversion <=== crash

if tu is unicode, the crash is normal (the line should be "return 
text.encode('utf-8')"), but I'm not sure to understand the intention 
here, so it probably need more investigation.
(Continue reading)

Ian Ward | 3 Oct 2011 02:03
Favicon
Gravatar

Re: Urwid 1.0.0: it seems broken

Goffi wrote on 2011-10-02 17:28:
> Unfortunately, I have bad news: after somebody used my XMPP client (with 
> a console frontend based on Urwid) he contacted me because of crashes.
> I saw he was using the new version, so I upgraded, and realized that my 
> frontend (primitivus, see http://wiki.goffi.org/wiki/Salut_%C3%A0_Toi if 
> you want the sources) is broken with this version.
> 
> I haven't tracked everything yet, but
> 
> - the method is_mouse_press is not available any more. After quickly 
> watching the sources, it seems to be now in urwid.util , but I see no 
> mention of that in the CHANGELOG.

I switched the __init__.py to explicitly export all its symbols and I
forgot to include is_mouse_press.  Now fixed in development and it will
be in 1.0.1.

A workaround would be to import is_mouse_press from urwid.util.

> - I have crashed in my app when I pressed an unicode key (like the 
> french "é"). I quickly looked the code and saw in widget.py, line 983 
> and beyong:
> 
>    tu = isinstance(text, unicode)
>    [...]
>    if tu:
>        return text.encode('ascii') # follow python2's implicit 
> conversion <=== crash
> 
> if tu is unicode, the crash is normal (the line should be "return 
(Continue reading)

Goffi | 3 Oct 2011 16:20

Re: Urwid 1.0.0: it seems broken

Thanks for your quick answer :)

> I switched the __init__.py to explicitly export all its symbols and I
> forgot to include is_mouse_press.  Now fixed in development and it will
> be in 1.0.1.

Great

> Are you sure your terminal is detected as using utf-8?  what does
>
>      import urwid; print urwid.get_encoding_mode()
>
> say?

% python -c "import urwid; print urwid.get_encoding_mode()"
utf8

(I'm using konsole on kubuntu 11.04)
Anyway I probably have non unicode strings in my code, I'll check it.

> We're talking about a few lines of code. I don't think that's a big
> duplication problem :-)

Of course, I was talking generally. Other stuff can be implemented

>    But, of course I'm happy to consider patches
> to Urwid with new widgets.  That's how the tree widgets were added to 1.0.0

Oki, the only issue is I'm far too busy to review my code, test it and 
propose patches for urwid at the moment. I hope I can do that in the 
(Continue reading)

Goffi | 8 Oct 2011 21:01

Re: Urwid 1.0.0: it seems broken

For the record, the issue was due to an Edit initialised with "> " 
caption. As it's with python 2.x, the string is not unicode, but the 
text I entered was.
So in _normalise_to_caption(widget.py l.970) tu is true, but cu is 
false, and the method try to encode the text unicode string to ascii (l. 
987), resulting in a crash.

I resolved it by using u"> " instead of "> "

cheers
Goffi

Le 03/10/2011 02:03, Ian Ward a écrit :
>
>> - I have crashed in my app when I pressed an unicode key (like the
>> french "é"). I quickly looked the code and saw in widget.py, line 983
>> and beyong:
>>
>>     tu = isinstance(text, unicode)
>>     [...]
>>     if tu:
>>         return text.encode('ascii') # follow python2's implicit
>> conversion<=== crash
>>
>> if tu is unicode, the crash is normal (the line should be "return
>> text.encode('utf-8')"), but I'm not sure to understand the intention
>> here, so it probably need more investigation.
> Edit widgets now try to convert their edit_text to the same type
> (unicode or bytes) as their captions.  If the caption is unicode but
> input received is bytes (because the terminal isn't detected to be in
(Continue reading)


Gmane