Rob Lanphier | 2 Feb 2010 20:19
Picon
Favicon
Gravatar

FloatEdit widget

Hi folks,


I'm working on a project that requires a FloatEdit instead of IntEdit, so I wrote one.  The file is attached here, and the latest version will generally be here:

(along with the rest of the project I'm working on, which isn't quite ready for primetime yet)

The single standalone file run on its own will pull up a test harness.  The test harness requires urwid 0.9.9, but the main FloatEdit widget works with 0.9.8.

Lemme know what you think.  I'm willing to work this into a patch if there's interest in including it in urwid directly (and feel free to vacuum this up if you're so inclined).  There's a couple of minor tweaks I would make if I were patching rather than bolting this on the side, which are noted in the code.

Rob
Attachment (floatedit.py): application/octet-stream, 8 KiB
_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Ian Ward | 2 Feb 2010 22:54
Favicon
Gravatar

Re: FloatEdit widget

Rob Lanphier wrote on 2010-02-02 14:19:
> Lemme know what you think.  I'm willing to work this into a patch if
> there's interest in including it in urwid directly (and feel free to
> vacuum this up if you're so inclined).  There's a couple of minor tweaks
> I would make if I were patching rather than bolting this on the side,
> which are noted in the code.

Thanks Rob, I've added it to my urwid-contrib repo:
https://excess.org/hg/urwid-contrib/file/

Your code looks good and I'm not averse to adding this sort of thing to
the library if other people find it useful.

Ian
Rob Lanphier | 8 Feb 2010 19:57
Picon
Favicon
Gravatar

TreeWidget/TreeWalker class

Hi folks,


In the process of writing my form building tool, I found myself wanting a TreeWidget class.  Seeing that browse.py included with urwid was pretty close to what I was looking for, I decided to take a crack at teasing out the generic bits from the overall code, resulting in the attached files.

Since I haven't done anything more than make sure that browse.py still works after the class extraction, I'll probably have more work to do to the base classes. Here's where I'll be doing that work:

I hope this is useful.  Let me know if you have any particular guidance on direction for this.

Thanks
Rob
p.s. I'll explain more about what I'm planning to do with this in a separate email.

Attachment (browse.py): application/octet-stream, 14 KiB
Attachment (treetools.py): application/octet-stream, 8 KiB
_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Rob Lanphier | 8 Feb 2010 20:14
Picon
Favicon
Gravatar

Advice on overhaul vs tweak

Hi folks,

As I alluded to in my last mail, the widget work I'm doing stems from a larger project I'm working on.  I'm building  a tool for taking a generic JSON schema, and building a UI for it using urwid.  The code for that project is here:

I'm looking for some advice.  Things on that project are going pretty well, but I'm worried that I painted myself into a corner with my current approach.  Due to the way I've nested the widgets, I don't seem to have a good way of reseting the focus. If you're feeling adventurous, you can grab the code, and try the following test:
*  Run ./jsonedit
*  Add a couple items to the list
*  Move the cursor to one of them, then type 'ctrl d' (delete node).  Notice that you can see your selection (and ignore the display quirks for now, as well as the fact that deletion doesn't actually work yet)
*  Add more items (enough that scrolling is needed to see the bottom of the list)
*  Select one of the bottom nodes
*  Notice that focus pops up to the top. 

My hunch is that my problems stem from not really having a good ListWalker in place.  As it stands, my ListBox widget contains one big widget, which in turn contains lots of subwidgets.  There was a comment that Ian made on IRC that I didn't fully understand at the time, but I think I'm coming into the exact problem that he warned me about.  He wrote: "just a general comment about deeply-nested widgets: they will be opaque to your ListBox, so scrolling might not behave the way you want".

Actually internalizing that realization lead me to looking at browse.py, and thus my work on separating out the TreeWalker from that code.  However, fitting everything into a new TreeWidget/TreeWalker regime looks like it's going to be a large overhaul to an existing part of my code.

My question: does my hunch about needing TreeWalker seem correct?   Is there an easier tweak I can make, or am I probably better off biting the bullet and doing the overhaul now?  I realize the answer is almost certainly going to be "it depends", but some general advice about handling focus issues would be much appreciated.

Rob
p.s. if this seems like an easier question to answer on IRC, feel free to ping me there.  I'm on #urwid as "robla"

_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Ian Ward | 9 Feb 2010 00:19
Favicon
Gravatar

Re: Advice on overhaul vs tweak

Rob Lanphier wrote on 2010-02-08 14:14:
> My question: does my hunch about needing TreeWalker seem correct?   Is
> there an easier tweak I can make, or am I probably better off biting the
> bullet and doing the overhaul now?  I realize the answer is almost
> certainly going to be "it depends", but some general advice about
> handling focus issues would be much appreciated.

The TreeWalker in browse.py is really set up to allow really lazy
loading of directory contents while still appearing to be viewing the
complete nested tree of files, including parent directories.  That has
made it more complicated than a common tree view where everything is
already in memory.

What the ListBox/ListWalker separation gives you is the ability to
create widgets (and load data or do other processing) lazily.  You can
also use it to delete objects as they scroll off screen so memory usage
doesn't grow in an unbounded way.

If you are always loading the complete JSON structure into memory, a
ListWalker could give you the ability to walk that structure directly
and create/delete widgets as required, but it's not a huge gain over
just creating a regular list of those widgets.

The bigger problem with having one big widget is that the whole thing
has to be rendered every time there is a change or screen resize,
including all the widgets off the screen..  definitely not good.

So yes, I think you should either create a ListWalker suited to your
data, or create a flat list of widgets (with SimpleListWalker) and sync
it with your structure on changes.

Ian
Rob Lanphier | 9 Feb 2010 01:10
Picon
Favicon
Gravatar

Re: Advice on overhaul vs tweak

On Mon, Feb 8, 2010 at 3:19 PM, Ian Ward <ian <at> excess.org> wrote:

So yes, I think you should either create a ListWalker suited to your
data, or create a flat list of widgets (with SimpleListWalker) and sync
it with your structure on changes.

Great, thanks for the helpful explanation!  It's pretty obvious what I'm doing now isn't working, so I'm in for an overhaul one way or another.  Fortunately, the overhaul is limited to one file out of the project

I'm going to have a run at extending the TreeWalker/TreeWidget code, since I think it eliminates enough accounting of dealing with expanded/collapsed nodes and adding/deleting nodes to be valuable.  Moreover, the process of abstracting that code was a great learning exercise for me, and as a result, I'm pretty comfortable navigating that chunk of code now.

Rob
 
_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Rob Lanphier | 13 Feb 2010 20:14
Picon
Favicon
Gravatar

Re: TreeWidget/TreeWalker class

I spent the past week hammering away at TreeWidget/TreeWalker, and I have something now that I'm pretty confident is a general purpose widget.  In addition to rewriting my own app to use it, I rewrote urwid's browse.py sample app to take advantage of it, which other than a couple minor cosmetic changes, performs identically to the version that ships with urwid.  Code is here: 

I didn't entirely eliminate the globals in browse.py, but they're no longer central to the operation of the widget, and it wouldn't be that much more work to get rid of them entirely.

Lemme know what you think.

Rob

On Mon, Feb 8, 2010 at 10:57 AM, Rob Lanphier <robla <at> robla.net> wrote:
In the process of writing my form building tool, I found myself wanting a TreeWidget class.  Seeing that browse.py included with urwid was pretty close to what I was looking for, I decided to take a crack at teasing out the generic bits from the overall code, resulting in the attached files.

Since I haven't done anything more than make sure that browse.py still works after the class extraction, I'll probably have more work to do to the base classes. Here's where I'll be doing that work:

I hope this is useful.  Let me know if you have any particular guidance on direction for this.

Thanks
Rob
p.s. I'll explain more about what I'm planning to do with this in a separate email.


_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Ian Ward | 14 Feb 2010 14:32
Favicon
Gravatar

Re: TreeWidget/TreeWalker class

Rob Lanphier wrote:
> I spent the past week hammering away at TreeWidget/TreeWalker, and I 
> have something now that I'm pretty confident is a general purpose 
> widget.  In addition to rewriting my own app to use it, I rewrote 
> urwid's browse.py sample app to take advantage of it, which other than a 
> couple minor cosmetic changes, performs identically to the version that 
> ships with urwid.  Code is here: 
> http://bitbucket.org/robla/urwid-treetools/

I see this is based on 0.9.8, would you update the code for 0.9.9 
(_get_w and _set_w instead of get_w and set_w, using MainLoop)  Also it 
would be nice to see how this modified code is used by another app to 
see the reasoning behind your changes.

It's quite a bit of extra code to include with the browse.py example, 
but it should be possible to incorporate some of the changes back.  Or 
with the changes above I could include your code in the urwid-contrib repo.

Ian
Rob Lanphier | 15 Feb 2010 06:09
Picon
Favicon
Gravatar

Re: TreeWidget/TreeWalker class

On Sun, Feb 14, 2010 at 5:32 AM, Ian Ward <ian <at> excess.org> wrote:

Rob Lanphier wrote:
> I spent the past week hammering away at TreeWidget/TreeWalker, and I
> have something now that I'm pretty confident is a general purpose
> widget.  In addition to rewriting my own app to use it, I rewrote
> urwid's browse.py sample app to take advantage of it, which other than a
> couple minor cosmetic changes, performs identically to the version that
> ships with urwid.  Code is here:
> http://bitbucket.org/robla/urwid-treetools/

I see this is based on 0.9.8, would you update the code for 0.9.9
(_get_w and _set_w instead of get_w and set_w, using MainLoop)

Okee doke.  I just pushed a version which I think syncs all of the important changes in browse.py made since 0.9.8.
 
 Also it
would be nice to see how this modified code is used by another app to
see the reasoning behind your changes.

I just pushed a new version of my app here which uses this code:

...but it's still in pretty rough shape, so it may not make the best example.  If I get the chance, I'll write a small sample app that demonstrates a simple use case.

 
It's quite a bit of extra code to include with the browse.py example,
but it should be possible to incorporate some of the changes back.  Or
with the changes above I could include your code in the urwid-contrib repo.


 Wherever works for you is fine by me.  I think it'll be pretty useful for folks, but I can understand not wanting to take on the maintenance burden of an unproven widget.

Rob

_______________________________________________
Urwid mailing list
Urwid <at> lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid
Ian Ward | 26 Feb 2010 00:11
Favicon
Gravatar

Urwid repos, manual, display modules

Hello all, here is a little collection of recent Urwid developments.

I've put up mirrors of the Urwid repository on bitbucket[1] and
github[2], and I'll try to keep them up to date going forward.
These sites can be really nice for collaboration, so if you've got
improvements for Urwid, feel free to fork it and send me a pull request.
Patches by email or this list are still welcome, of course.

[1] http://bitbucket.org/wardi/urwid/
[2] http://github.com/wardi/urwid

I've also spent some time on the long-neglected Urwid User Manual[3].
There's still a few sections left to fill in, but I would appreciate
your comments or fixes to what's there right now.

[3] http://excess.org/urwid/wiki/UrwidManual

On IRC a few days ago someone suggested the idea of using Urwid to drive
a small LCD panel with a few buttons.  This person also needs the code
to be based on Glib, which fortunately is already supported.  I quite
like the idea, so I'm hoping to write a display module for a similar
device[4] in the near future.

Also, Ali Afshar has recently contributed[5][6] a really nice display
module based on Twisted Conch.  This module lets you serve many SSH
clients from the same Urwid application, each user with their own interface.

[4] http://www.crystalfontz.com/product/XES635BK-TFE-KU.html
[5] https://excess.org/hg/urwid-contrib/file/
[6] http://bitbucket.org/aafshar/txurwid-main/src/

If you're doing something interesting with Urwid, please say "hi" on the
list or on IRC.  It would be great to hear from you.  If you've released
some code based on Urwid, please add a link to the application list[6].

[6] http://excess.org/urwid/wiki/ApplicationList

Ian

Gmane