[Urwid] Enhancements for Urwid

Florian Festi ffesti at redhat.com
Tue Feb 6 08:33:19 EST 2007


Hi!

This is all great news.

I just saw your ticket tracker after sending my mail. So I could have 
reduced my list to "All tracker items plus some others"

I won't answer every single issue as most of them are already on "Go" and we 
will address details during implementation.

So how do we proceed from here? Am fine with sending in patches or python 
file for new widgets. But how are we going to do further planning. I 
personally prefer wiki pages over posting based solutions like mail or 
tracker. But that's up to you.

We also should meet in IRC. When are you reachable there? We are normally 
working around 8:00-18:00 UTC but other times of day are fine for me too (as 
long as its not daily) with extending into the evening is easier than 
getting up early ;)=

>>  * Paned (h/v)
> I think you can do something like this with Columns and Pile widgets. If 
> not, could you be more specific?
The difference to Columns and Pile is that the user can change the widths 
interactively. So they'd be subclasses of Columns and Pile.

> related to http://excess.org/urwid/ticket/6
> As with the Menu item above, this will be a lot easier once some canvas 
> changes I'm working on right now are released.
I am already curious. We'll urgently need better overlaying support. Are 
your changes already in trunk?

>> Other features:
>>  * Stacking: Having a sane way of putting widgets on top of each
>>    other. These needs so be on a global level to avoid limitations
>>    as in Overlay.
> Would you give an example of what you are trying to do that is difficult 
> in Urwid.

This is more or less the overlay/popup/pull down/dialog stuff again. When it 
comes to dialogs problems with overlapping are even more interesting. 
Especially if you start rising/lowering dialogs with active popups ;)=

>>  * Sensitivity: Disable parts of the UI depended on other selections
> We could add a disabled state to all the usual widgets, but that would 
> probably mean telling them to draw themselves in a different attribute 
> (the themeing suggestion might help there)
>>  * (In)Visibility: Hide parts of the UI depended on other selections
> This is hard to do right now.  It would be easier if referencing widgets 
> within their containing widgets was easier.
We'll delay this until theming and a container interface is in place.

>>  * Support for a more dialog driven interface design
> Yes, as an option.
 >
> I'm happy to extend the library in that direction, as long as it remains 
> easy to create keyboard-focused interfaces for people that prefer to 
> create console apps such as irssi and vim.
We are in no way planning to remove these capabilities from the library. But 
I want to make clear that we have a different focus and a different 
viewpoint. If the whole list gets implemented that's a big step forward for 
urwid but also a big step away from where it is now. Of course we'll be 
playing nice but you as the main developer have to keep the spirit of urwid 
up and have a look that we don't turn it into something completely different.


About further steps:

First things I'd like to do is elaborating how theming should work and may 
be streamline some of the interfaces like containers as this blocks other 
stuff. We'll work on some of the widgets in parallel as most of them don't 
have any dependencies.


Thank you for you fast and friendly answer

Florian




More information about the Urwid mailing list