gmane.comp.lib.urwid

GridFlow scrolling and focus

Eric Easley — 2012-05-24T18:29:54

To Whom It May Concern:

If a GridFlow is larger than the screen, it can be scrolled through. However, if
GridFlow X loses focus, by switching focus to another widget in a pile or column
for example, GridFlow X shows only the first cells of the GridFlow rather than
those around the former focus cell. A minimal example can be found at
http://pastebin.com/6X0vNMAq . Run the script, scroll down so that Button 0 is
no longer showing and hit 'tab'. Focus will switch to the second GridFlow, but
the first GridFlow now show button 0 again as though it had never scrolled.

I would expect the GridFlow to retain its 'position' even without focus, like
ListBox does. Is this a strange expectation or is GridFlow's behavior strange?
To change this behavior, would GridFlow require calculate_visible() like
ListBox? Thank you.

Sincerely,
Eric Easley

Re: Problem with Text and Listbox Widgets

Ian Ward — 2012-05-07T12:41:29

On May 7, 2012 5:47 AM, "Rupp, Lawrence E" <lawrence.e.rupp< at >boeing.com>
wrote:
update occurs, the text is inserted but is padded on the right to the
column limit with question marks.
that will help you narrow it down, so let me know what you need.

A minimal example that reproduces the problem would be perfect :-)

IIRC the only thing in urwid that adds question marks is a filter on
control characters being sent to the screen.  Is there a chance there are
some control characters in the text you're passing?


Ian
_______________________________________________
Urwid mailing list
Urwid< at >lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid

Re: Problem with Text and Listbox Widgets

Rupp, Lawrence E — 2012-05-07T09:46:55

I have a Text widget that I am updating with 'set_text' and when the update occurs, the text is inserted but is padded on the right to the column limit with question marks.  

Any idea what is causing this?  I don't know what information to provide that will help you narrow it down, so let me know what you need.

I am using Python 2.4.

Thanks,

larry


Lawrence Rupp
P8 Trainer Software
(253) 657-9661
lawrence.e.rupp< at >boeing.com

Re: Problem with Text and Listbox Widgets

Rupp, Lawrence E — 2012-04-12T22:50:41

 Ian,

It was a newline problem, just like you thought.  I searched the internet on how to strip off a newline, found the 'rstrip()' function, applied it in my code, and VOILA!  No more line appending on my GUI.

Moochas Grass for pointing out the obvious!  May all your problems today be of a similar nature!

Larry


-----Original Message-----
From: urwid-bounces< at >lists.excess.org [mailto:urwid-bounces< at >lists.excess.org] On Behalf Of Ian Ward
Sent: Thursday, April 12, 2012 3:36 PM
To: Urwid General Discussion
Subject: Re: [Urwid] Problem with Text and Listbox Widgets

On Thu, Apr 12, 2012 at 5:52 PM, Rupp, Lawrence E <lawrence.e.rupp< at >boeing.com> wrote:

That shouldn't happen.  Can you post some code that demonstrates the problem you're having?  Are you sure the text you're inserting doesn't have a trailing newline?

_______________________________________________
Urwid mailing list
Urwid< at >lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid

Re: Problem with Text and Listbox Widgets

Rupp, Lawrence E — 2012-04-12T22:43:56

Ian,

Darn, now that you mention it, it just might.  The text that I am inserting is coming from a 'print' statement in a subprocess through a pipe.  It may well have a 'newline' automatically appended.  I didn't consider that because some of the text that is passed is converted to integers in the main process, and the newline problem doesn't appear with ints.

Is there some other way to pass data back through a pipe than with a print statement?  Maybe a function 'return' or something? 

Thanks for the quick response, Ian, and thanks for the 2nd point of view.  I'll check the return through the pipe and let you know either way.

Larry


-----Original Message-----
From: urwid-bounces< at >lists.excess.org [mailto:urwid-bounces< at >lists.excess.org] On Behalf Of Ian Ward
Sent: Thursday, April 12, 2012 3:36 PM
To: Urwid General Discussion
Subject: Re: [Urwid] Problem with Text and Listbox Widgets

On Thu, Apr 12, 2012 at 5:52 PM, Rupp, Lawrence E <lawrence.e.rupp< at >boeing.com> wrote:

That shouldn't happen.  Can you post some code that demonstrates the problem you're having?  Are you sure the text you're inserting doesn't have a trailing newline?

_______________________________________________
Urwid mailing list
Urwid< at >lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid

Re: Problem with Text and Listbox Widgets

Ian Ward — 2012-04-12T22:36:08

On Thu, Apr 12, 2012 at 5:52 PM, Rupp, Lawrence E
<lawrence.e.rupp< at >boeing.com> wrote:

That shouldn't happen.  Can you post some code that demonstrates the
problem you're having?  Are you sure the text you're inserting doesn't
have a trailing newline?

Problem with Text and Listbox Widgets

Rupp, Lawrence E — 2012-04-12T21:52:48

Hi,

I am a complete newbie to both Python and Urwid, and I have a question regarding widget behavior.

I am building a status gui composed of Text widgets in a Listbox, traversed by a SimpleListWalker.

The problem I'm having is that when I update one of the Text widgets with 'varname.set_text("example"), the text string "example" appears in the appropriate Text widget, but it also appears to add a carriage return, meaning the entire display below the updated Text widget shifts down one line.  How do I prevent this from happening?  How can I simply overwrite what was in the Text widget in the first place without a new line showing up?

BTW, I am using Urwid1.0.1 and Python 2.4.

Thanks,

Larry

Re: Container Help

Andrew Higginson — 2012-04-12T15:57:50

Thanks again :)

--
Andrew

Re: MainLoop's pipe is not removed after pipe data ends.

Andrew Wu — 2012-04-12T13:19:26

Ian Ward <ian< at >excess.org> 於 2012年4月11日上午3:03 寫道：


Yes, this is my idea:
==
--- urwid_bak/main_loop.py    2012-04-03 19:20:16.000000000 +0800
+++ urwid/main_loop.py    2012-04-12 20:44:11.000000000 +0800
< at >< at > -184,10 +184,9 < at >< at >

         def cb():
             data = os.read(pipe_rd, PIPE_BUFFER_READ_SIZE)
-            rval = callback(data)
-            if rval is False:
-                self.event_loop.remove_watch_file(watch_handle)
-                os.close(pipe_rd)
+            callback(data)
+            if data == "":
+                self.remove_watch_pipe(pipe_wr)

         watch_handle = self.event_loop.watch_file(pipe_rd, cb)
         self._watch_pipes[pipe_wr] = (watch_handle, pipe_rd)
==

The client code gets writer_fd from watch_pipe. The client code is always
responsible for closing writer_fd.

If MainLoop object detected the pipe reached EOF(an empty string is read,
which means writer_fd is closed, and no more data left in the pipe), it
calls remove_watch_pipe to closes reader_fd and does the cleanup.

The client code can also call remove_watch_pipe by itself, but in this
case, the client code still need to close writer_fd.

The callback function doesn't need to return any value. I think this
interface may be more understandable?

Or, the MainLoop may use Queue to communicate with other threads, by adding
methods like watch_queue and remove_watch_queue. In this case, we don't
have to worry about leaking fds, and data in Queues is easier to be
processed than in pipes.
_______________________________________________
Urwid mailing list
Urwid< at >lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid

Re: Container Help

Ian Ward — 2012-04-12T12:54:07

Sure, just put Divider widgets between the buttons and give them a weighted
width and the remaining space will be distributed across them.

Ian
On Apr 12, 2012 4:45 AM, "Andrew Higginson" <at.higginson< at >gmail.com> wrote:

_______________________________________________
Urwid mailing list
Urwid< at >lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid

Container Help

Andrew Higginson — 2012-04-12T08:45:48

Hi,

I have an issue which is that I want a set of buttons to be packed
horizontally.

I want each button to only be its minimum width (i.e. not grow to fill
space) and I don't want each button to be the same width (i.e. not
homogeneous), they should be different

I also want the spacing in between each button to grow according to the
width of the screen (the spacing should be equal)

The issue I have is that when I pack buttons into an urwid.Columns, the
buttons are all the same width and therefore as wide as the widest
button. If I pack them as fixed items, the issue goes away however the
spacing between each item does not grow to fit the screen, it remains
constant (as set by the dividechars argument)

Is there a way for me to achieve what is described? :)

Thanks

--
Andrew

Re: Centering Button Text

Andrew Higginson — 2012-04-11T16:18:43

Wow, that was easier than I thought :)

Thanks Ian

--
Andrew

Re: MainLoop's pipe is not removed after pipe data ends.

Ian Ward — 2012-04-10T19:03:48

On Fri, Apr 6, 2012 at 8:29 AM, Andrew Wu

That does seem to make more sense.

Now that I'm looking at it though I don't like the interface.  As in
your test code you need to add a comment on "return False" to
understand what is actually going to happen.

Using something like this might be an improvement:

  return "close pipe"

There is also the problem of leaking fds.  The write fd is not closed
by remove_watch_pipe (as documented).  Maybe an optional parameter to
close both ends would help?

Now it seems like there shouldn't be a special way to close a pipe
with a handler's return value (getting too complicated)

Thoughts?

Ian

Re: Centering Button Text

Ian Ward — 2012-04-10T13:17:23

On Tue, Apr 10, 2012 at 6:36 AM, Andrew Higginson
<at.higginson< at >gmail.com> wrote:

Button's _label attribute is a Text subclass, so this works:

  my_button._label.align = 'center'

You could add that to the __init__ of a Button subclass if you like.

Ian

Questions about Buttons and Columns

Andrew Higginson — 2012-04-10T10:36:31

Hi,

So I am new to urwid and need some help :)

I have a set of buttons packed with an urwid.Columns and I would like
the text inside each buttons to be centered
Currently it looks like this  but as you can see, the text is aligned to
the left

If there is not a method/easy way to achieve this, and it requires some
sub-classing, could you give me some pointers on how to do it?

Thanks

--
Andrew

Centering Button Text

Andrew Higginson — 2012-04-10T10:36:41

Hi,

So I am new to urwid and need some help :)

I have a set of buttons packed with an urwid.Columns and I would like
the text inside each buttons to be centered
Currently it looks like this  but as you can see, the text is aligned to
the left

If there is not a method/easy way to achieve this, and it requires some
sub-classing, could you give me some pointers on how to do it?

Thanks

--
Andrew

MainLoop's pipe is not removed after pipe data ends.

Andrew Wu — 2012-04-06T12:29:55

Test code:
===
import urwid
import os

txt = urwid.Text(u"Hello World")
fill = urwid.Filler(txt, 'top')

def show_or_exit(input):
    if input in ('q', 'Q'):
        raise urwid.ExitMainLoop()

loop = urwid.MainLoop(fill, unhandled_input=show_or_exit)

def callback(data):
    if data == "":
        # data end, return False, watch will be removed.
        return False
    return True

fd = loop.watch_pipe(callback)
# write some data into pipe.
f = os.fdopen(fd, "w", 1)
f.write("hello")
f.close()

print "before loop.run():"
print "loop.event_loop._watch_files:"
print loop.event_loop._watch_files
print "loop._watch_pipes:"
print loop._watch_pipes

# press Q to break.
loop.run()

print "after loop.run():"
print "loop.event_loop._watch_files:"
print loop.event_loop._watch_files
print "loop._watch_pipes:"
print loop._watch_pipes
===
Run the test code and press Q to quit, the output is:

before loop.run():
loop.event_loop._watch_files:
{5: <function cb at 0xb7c36144>}
loop._watch_pipes:
{6: (5, 5)}

after loop.run():
loop.event_loop._watch_files:
{}
loop._watch_pipes:
{6: (5, 5)}

You can see that pipe in _watch_files list is removed correctly, but pipe
in _watch_pipes list is not removed. I think it is not right.

But if I do this patch:
===
--- urwid_bak/main_loop.py    2012-04-03 19:20:16.000000000 +0800
+++ urwid/main_loop.py    2012-04-06 20:18:20.000000000 +0800
< at >< at > -186,8 +186,7 < at >< at >
             data = os.read(pipe_rd, PIPE_BUFFER_READ_SIZE)
             rval = callback(data)
             if rval is False:
-                self.event_loop.remove_watch_file(watch_handle)
-                os.close(pipe_rd)
+                self.remove_watch_pipe(pipe_wr)

         watch_handle = self.event_loop.watch_file(pipe_rd, cb)
         self._watch_pipes[pipe_wr] = (watch_handle, pipe_rd)
===

The output becomes:

before loop.run():
loop.event_loop._watch_files:
{5: <function cb at 0xb7b7b9cc>}
loop._watch_pipes:
{6: (5, 5)}

after loop.run():
loop.event_loop._watch_files:
{}
loop._watch_pipes:
{}

Both _watch_pipes list and _watch_files list are now correct.
_______________________________________________
Urwid mailing list
Urwid< at >lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid

Re: MainLoop.remove_watch_pipe doesn't work?

Ian Ward — 2012-03-08T14:38:55

work:####import urwidtxt = urwid.Text(u"Hello World")fill = urwid.Filler(txt,
'top')loop = urwid.MainLoop(fill)def callback(data):    passfd =
loop.watch_pipe(callback)loop.remove_watch_pipe(fd)loop.run()####I got error
message:Traceback (most recent call last):  File "t.py", line 11, in <module>
205, in remove_watch_pipe    watch_handle, pipe_rd =
self._watch_pipes.remove(write_fd)AttributeError: 'dict' object has no
attribute
'remove'

Hmm.  I must have spam filter issues because I didn't see this email.

Thanks for the bug report, that looks like it should have been a del
self._watch_pipes[write_fd].

Ian

feature-containers merge

Ian Ward — 2012-03-07T21:51:52

Hello everyone!

I'm happy to announce the containers changes I've been working on for a few
months have now landed in the default/master branch.  This is a long post
but there's lots of good stuff here.  If you see a problem with the API or
its implementation now's the time to let me know!


CONTENTS

 1. New Container API
 2. Container and Decoration Widget Improvements
 3. List Walker API V2
 4. New Simple List Walker and Monitored List Types


1. NEW CONTAINER API

Urwid's container widgets:

 * Columns
 * Pile
 * GridFlow
 * Overlay
 * Frame
 * ListBox

All now have a common container API you can use, regardless of the
container type.  Backwards compatibility is still maintained for the old
container-specific ways of accessing and modifying contents, but the new
API is now the preferred way of modifying and traversing containers.


  cont.focus

is a read-only property that returns the widget in focus for this
container.  Empty containers and non-container widgets (that inherit from
Widget) will return None.


  cont.focus_position

is a read/write property that provides access to the position of the
container's widget in focus.  This will often be a integer value but may be
any object*.  Reading this value on an empty container or on any
non-container widgets (that inherit from Widget) raises an IndexError.
 Writing to this property with an invalid position will also raise an
IndexError.  Writing a new value automatically marks this widget to be
redrawn and will be reflected in cont.focus.

* Columns, Pile, GridFlow, Overlay and ListBox with a SimpleListWalker or
SimpleFocusListWalker as its body use integer positions;  Frame uses
'body', 'header' and 'footer';  ListBox with a custom list walker will use
the positions the list walker returns


  cont.contents

is a read-only property** that provides access to an mapping- or list-like
object that contains the child widgets and the options used for displaying
those widgets in this container.  The mapping- or list-like object always
allows reading from positions with the usual __getitem__ method and may
support assignment and deletion*** with __setitem__ and __delitem__
methods.  The values are (child widget, option) tuples.  When this object
or its contents are modified the widget is automatically flagged to be
redrawn.

** Columns, Pile and GridFlow also allow assigning an iterable to this
property and overwrite the values in their contents list with the ones
provided.

*** Columns, Pile, GridFlow, Overlay and Frame support item assignment and
deletion


  cont.options(...)

is a method that returns options objects for use in items added to
cont.contents.  The arguments are specific to the container type, and
generally match the __init__ arguments for the container.  The objects
returned are currently tuples of strings and integers or None for
containers without child widget options.  This method exists to allow
future versions of Urwid to add new options to existing containers.  Code
that expects the option tuples to remain the same size will fail when new
options are added, so defensive programming with options tuples is strongly
encouraged.


  cont.__getitem__(x)  # <=>  cont[x]

is a short-cut method behaving identically to:
cont.contents[x][0].base_widget.  Which means roughly "give me the child
widget at position x and skip all the Decoration widgets wrapping it".
 Decoration widgets include Padding, Filler, AttrMap etc.


  cont.get_focus_path()

is a method that returns the focus position for this container *and* all
child containers along the path defined by their focus settings.  This list
of positions is the closest thing we have to the singular widget-in-focus
in other UI frameworks, because the ultimate widget in focus in Urwid
depends on the focus setting of all its parent container widgets.


  cont.set_focus_path(p)

is a method that assigns to the focus_position property of each container
along the path given by the list of positions p.  It may be used to restore
focus to a widget as returned by a previous call to cont.get_focus_path().


  cont.__iter__()  and cont.__reversed__()

are methods that allow iteration over the *positions* of this container.
 Normally the order of the positions generated by __reversed__() will be
the opposite of __iter__().  The exception is the case of ListBox with
certain custom list walkers, and the reason goes back to the original way
list walker interface was defined.  Note that a custom list walker might
also generate an unbounded number of positions, so care should be used with
this interface and ListBoxes.


2. CONTAINER AND DECORATION WIDGET IMPROVEMENTS

I made a number of other improvements to the container and decoration
widgets:

 * GridFlow child widgets may now be given different widths, and more types
of widths will likely be added in the future to make it a much more
flexible container

 * GridFlow, Columns, Overlay and Padding now consistently use the names
width_type and width_amount

 * width_types formerly called 'fixed' for a set number of screen columns
are now called 'given' to avoid confusion with fixed widgets, 'fixed' is
still accepted for backwards compatibility

 * width_types formerly called 'flow' for asking a widget to calculate its
own number of screen columns is now called 'pack' to avoid confusion with
flow widgets, 'flow' is still accepted for backwards compatibility

 * Pile, Overlay and Filler now consistently use the names height_type and
height_amount

 * height_types formerly called 'flow' (or None) for asking a widget to
calculate its own number of rows are now called 'pack' to be consistent
with width_type, 'flow' (and None) is still accepted for backwards
compatibility

 * Filler now has top and bottom parameters like Padding's left and right
parameters

 * Overlay now has min_height, min_width, left, right, top and bottom
parameters which behave like the same options on Padding and Filler

 * Frame now has some better docstrings and a comparison to a similar use
of Pile

 * Updated tour.py example to use new container/decoration parameters

 * FlowWidget, BoxWidget and FixedWidget are now deprecated, sizing is
given by a sizing() method or from the _sizing property/attribute


3. LIST WALKER API V2

The current list walker API ("V1") will remain available and is still the
least restrictive option for the programmer.  The list walker API V2 is an
attempt to remove some of the duplicate code that V1 requires for many
users.  List walker API V1 will be implemented automatically by subclassing
ListWalker and implementing the V2 methods:

 * walker.__getitem__(p)  # return widget at position p or raise an
IndexError or KeyError

 * walker.next_position(p)  # return position following position p or raise
an IndexError or KeyError

 * walker.prev_position(p)  # return position preceding position p or raise
an IndexError or KeyError

 * walker.set_focus(p)  # same as V1, may call self._modified()

 * walker.focus  # attribute or property containing the focus position, or
define walker.get_focus() as in V1


Also, there is an optional iteration helper method that may be defined in
any list walker.  When this is defined it will be used by
ListBox.__iter__() and ListBox.__reversed__():

 * walker.positions(reverse=False) # return a forward or reverse iterable
of positions


4. NEW SIMPLE LIST WALKER AND MONITORED LIST TYPES

For some time there has been an unpublicised monitored list type in Urwid:
MonitoredFocusList.  This class is a list with a .focus position attribute
that is automatically updated as the contents of the list changes.  i.e. If
you remove or insert items before the focus position using any of the
normal list methods the focus position is updated accordingly.  This class
is now used by a number of the container widgets to manage their contents
lists, and is the type of object that is returned when you access their
.contents property.

SimpleListWalker has for a long time been the recommended list walker for
the common case of using a normal list of widgets in a ListBox.
 SimpleListWalker uses the MonitoredList type to track its contents and
focus, and that can't be changed without possibly breaking existing code.

So, the new recommended simple list walker is SimpleFocusListWalker.
 SimpleFocusListWalker uses MonitoredFocusList and gets all its nice
focus-position-updating goodness.

I know.  Sorry about the long name.  I couldn't think of something better,
but suggestions are welcome.


That's it.  Hey, thanks for reading this far and happy Urwidding!

Ian
_______________________________________________
Urwid mailing list
Urwid< at >lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid

MainLoop.remove_watch_pipe doesn't work?

Andrew Wu — 2012-02-15T08:24:19

Hello,

I tried to call MainLoop.remove_watch_pipe, but it doesn't work:

####

import urwid

txt = urwid.Text(u"Hello World")
fill = urwid.Filler(txt, 'top')
loop = urwid.MainLoop(fill)

def callback(data):
    pass

fd = loop.watch_pipe(callback)
loop.remove_watch_pipe(fd)

loop.run()

####

I got error message:

Traceback (most recent call last):
  File "t.py", line 11, in <module>
    loop.remove_watch_pipe(fd)
  File "/home/Andrew Wu/urwid/main_loop.py", line 205, in remove_watch_pipe
    watch_handle, pipe_rd = self._watch_pipes.remove(write_fd)
AttributeError: 'dict' object has no attribute 'remove'
_______________________________________________
Urwid mailing list
Urwid< at >lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid

Re: ListBox loses focus

Martin Siebel — 2012-02-14T10:03:49

Hello Ian,

thanks for the fast help. I looked already into the _set_focus_complete code once, but could not really see what path is executed under which conditions (pending focusses etc.).

I was not aware that the change in focus occurs only before the size of the ListBox is known.Knowing this I, can just make a call to ListBox.render() in my widgetWrapper.render() before setting the focus and returning the actual ListBox.render() result.
I just tried it, it seems to work just fine.

Thank you!
Martin



________________________________
 Von: Ian Ward <ian< at >excess.org>
An: Martin Siebel <lonequestor< at >yahoo.de>; Urwid General Discussion <urwid< at >lists.excess.org> 
Gesendet: 16:48 Montag, 13.Februar 2012
Betreff: Re: [Urwid] ListBox loses focus
 

Good find.

So, the reason for this is that ListBox is trying very hard to maintain the screen column from its initial selected item (the first Columns) and the one you switched focus to.  This is because commonly the focus changes as a result of the user pressing up/down.

This screen column isn't set until the ListBox knows its own size (such as when render() is called) and when it does it doesn't know that it is clobbering a setting that you wanted to take precedence.  All this code is in ListBox._set_focus_complete() if you want to take a look.

ListBox.set_focus() should probably set a flag that indicates not to try and maintain the screen column when _set_focus_complete is eventually called.

Ian


On Thu, Feb 9, 2012 at 6:55 PM, Martin Siebel <lonequestor< at >yahoo.de> wrote:

Hello,
sp;                    
 j)
 16))])
sp;                    
 f.close()
 l]),
 (id(i),
 j)
 MyListBox(urwid.SimpleListWalker([urwid.Columns(buttons[3*i:3*i+3])
 35364624], focus is on 0
Urwid mailing list
Urwid< at >lists.excess.org
http://lists.excess.org/mailman/listinfo/urwid