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