[Urwid] Enhancements for Urwid

[Ian Ward]

Florian Festi wrote:
> 
> 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.

I will try using the Wiki pages you have started at 
http://excess.org/urwid/wiki/Development

> 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 ;)=

That's a little early for me, but I should be there from time to time. 
If you feel like having a "meeting" that can be arranged.

Perhaps I should start doing my hacking early in the morning (and learn 
a little German :-)

>> 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?

Partially.  I am going to extend the CompositeCanvas class to have a 
pointer to the widget that drew it, and a list of the canvases it 
contains.

I will add a generic way to propagate coordinates up the CompositeCanvas 
objects. Right now the cursor location is the only coordinates 
propagating. For things like drop-down menus it would be nice to say "I 
want to pop up a window starting here" and let a modified Overlay widget 
that covers more of the screen display the pop up.

The same thing could be used to indicate to scroll bars where the top 
and bottom of the visible scrolling region are on the screen, so that 
they will be drawn the correct size and location.

>>> 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 ;)=

Overlays can be nested as the foreground or background of other 
overlays.. maybe I'm not understanding properly.

>>>  * 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.

With respect to cleaning up the hierarchy of widgets, I was actually 
considering creating some new base classes:  ContentWidget and 
CompositeWidget.  All widgets fall into one or the other category, and 
the CompositeWidgets should be sharing a lot of code (eg. should be just 
specifying the locations of the widgets they contain, not do the 
rendering themselves)

Of course, a common CompositeWidget base class would help with creating 
a standard container interface.

FlowWidget, BoxWidget, and FixedWidget are actually more like behaviours 
than base classes - they depend on how they are called, not some 
intrinsic property.


Theming could be accomplished with a factory module, for example:

   from urwid.bluesteel_theme import *
   bluesteel_button = Button("Hello")

ie. Button is a function defined in urwid.bluesteel_theme that has a 
certain type of decoration and is wrapped in an AttrWrap with attributes 
from urwid.bluesteel_theme.default_palette (a list of attributes to be 
passed to set_palette)

Ian