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
_______________________________________________
Urwid mailing list
[email protected]
http://lists.excess.org/mailman/listinfo/urwid
