headers
Dominic LoBue | 5 Nov 2009 23:42
Picon

Determining number of rows available to frame body?

Hey,

Subject line pretty much says it all. I'm using a frame as my
top-level widget, and the body of the frame is a listbox which gets
the whole screen save the bottom border.

I need to know how many rows I have available to work with in the
listbox, but none of the available methods seem to give me a straight
answer. Any ideas?

Dominic
Permalink | Reply | 2 comments |
headers
Ian Ward | 5 Nov 2009 23:50
Favicon
Gravatar

Re: Determining number of rows available to frame body?

Dominic LoBue wrote:
> Hey,
> 
> Subject line pretty much says it all. I'm using a frame as my
> top-level widget, and the body of the frame is a listbox which gets
> the whole screen save the bottom border.
> 
> I need to know how many rows I have available to work with in the
> listbox, but none of the available methods seem to give me a straight
> answer. Any ideas?

The actual size of the ListBox will be passed in to the ListBox's
render(), keypress() and mouse_event() methods when they are called.
You could insert your own (perhaps WidgetWrap-based) widget between the
ListBox and the Frame and intercept that value, or you could override
the methods in a ListBox subclass.

If you want to calculate it yourself, separate from the widget classes
you could just subtract the number of rows in the footer from the total
screen size using your footer widget's rows() method.  This won't work
if you ever change your layout, though.

If this is still unclear, please post a short example of what you're
trying to do to to the list.

Ian
Permalink | Reply | 1 comment |
headers
Dominic LoBue | 6 Nov 2009 01:03
Picon

Re: Determining number of rows available to frame body?

On Thu, Nov 5, 2009 at 2:50 PM, Ian Ward <ian <at> excess.org> wrote:
> Dominic LoBue wrote:
>> Hey,
>>
>> Subject line pretty much says it all. I'm using a frame as my
>> top-level widget, and the body of the frame is a listbox which gets
>> the whole screen save the bottom border.
>>
>> I need to know how many rows I have available to work with in the
>> listbox, but none of the available methods seem to give me a straight
>> answer. Any ideas?
>
> The actual size of the ListBox will be passed in to the ListBox's
> render(), keypress() and mouse_event() methods when they are called.
> You could insert your own (perhaps WidgetWrap-based) widget between the
> ListBox and the Frame and intercept that value, or you could override
> the methods in a ListBox subclass.
>
> If you want to calculate it yourself, separate from the widget classes
> you could just subtract the number of rows in the footer from the total
> screen size using your footer widget's rows() method.  This won't work
> if you ever change your layout, though.
>
> If this is still unclear, please post a short example of what you're
> trying to do to to the list.
>
> Ian
>
>
> _______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominic LoBue | 6 Nov 2009 06:25
Picon

Simple example prog for signals

Ian,

Below is the source to a very simple example script I wrote to help me
better understand how signals in Urwid work. I thought I'd share, in
case someone else was having as hard a time figuring out how to use
signals as I was.

On an unrelated note, can you include __slots__ in all Urwid classes?
The program I'm writing with Urwid is eating up an excessive amount of
ram, and one of the tips I found for reducing python's memory
footprint is to use a __slots__ attribute which replaces the
memory-inefficient __dict__ with a tuple. :) Unfortunately it doesn't
work if one of the base classes doesn't use the __slots__ attribute
either. :(

Dominic

____code below______
#!/usr/bin/env python

import urwid

class sigsender(object):
    __metaclass__ = urwid.MetaSignals
    signals = ['sig']
    def __init__(self):
        urwid.Signals.connect(self, 'sig', self.cb)
    def con(self, kin):
        if kin is self:
            pass
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mateusz Biliński | 6 Nov 2009 09:31
Picon

Bash inside Urwid-based app

Hi,
I'm wondering wether it is possible to embed Bash (in general: shell)
inside Urwid-based app?

I want to make "toolbar" at the bottom to show additional info while
user can still use Bash in interactive mode (or at least: read-only).

Thanks for the answer in advance.

-- Mateusz Biliński
Permalink | Reply | 3 comments |
headers
Erik Osheim | 6 Nov 2009 14:59
Favicon

Re: Bash inside Urwid-based app

On Fri, Nov 06, 2009 at 09:31:49AM +0100, Mateusz Bili?ski wrote:
> I want to make "toolbar" at the bottom to show additional info while
> user can still use Bash in interactive mode (or at least: read-only).

Have you looked at screen? It's possible to configure it to display
whatever output you want (via a script) at the bottom while still
giving you an interactive shell at the top.

The advantage of screen is that it actually emulates a terminal, so you
could run top or whatever in the top screen. AFAIK an urwid program
would essentially have to reimplement this behavior.

That said, you should be able to do this via subprocess.Popen(['bash'],
...) or something.

-- Erik
Permalink | Reply | 0 comments |
headers
Ian Ward | 6 Nov 2009 15:05
Favicon
Gravatar

Re: Bash inside Urwid-based app

Mateusz Biliński wrote:
> Hi,
> I'm wondering wether it is possible to embed Bash (in general: shell)
> inside Urwid-based app?
> 
> I want to make "toolbar" at the bottom to show additional info while
> user can still use Bash in interactive mode (or at least: read-only).

AFAIK no-one has tried creating a virtual TTY widget, which is what 
you'd need to run console applications inside Urwid.   It's actually a 
fairly tricky thing to do properly, but if you're up for a challenge you 
could give it a try.  :-)  Looking at how the "screen" program, or any 
terminal emulator works would be a good start.

Ian
Permalink | Reply | 1 comment |
headers
Ian Ward | 6 Nov 2009 15:10
Favicon
Gravatar

Re: Simple example prog for signals

Dominic LoBue wrote:
> Ian,
> 
> Below is the source to a very simple example script I wrote to help me
> better understand how signals in Urwid work. I thought I'd share, in
> case someone else was having as hard a time figuring out how to use
> signals as I was.

Thanks, I'll add it to the contributed examples.

> 
> On an unrelated note, can you include __slots__ in all Urwid classes?
> The program I'm writing with Urwid is eating up an excessive amount of
> ram, and one of the tips I found for reducing python's memory
> footprint is to use a __slots__ attribute which replaces the
> memory-inefficient __dict__ with a tuple. :) Unfortunately it doesn't
> work if one of the base classes doesn't use the __slots__ attribute
> either. :(

Sounds interesting. If you send a patch I will consider it.

Ian
Permalink | Reply | 0 comments |
headers
Ian Ward | 6 Nov 2009 15:25
Favicon
Gravatar

Preparing for 0.9.9

I am in the final stages of preparing the next Urwid release built from 
the development version.  I have updated the tutorial and reference, and 
  am now working on updating the examples to use the new MainLoop class.

If you have code that depends on Urwid, please clone the development 
branch and verify that your code still works with the new version.  I'd 
like to catch as many regressions as I can before the release.

Known Incompatibilities:

The one big backwards-incompatible change is to WidgetWrap. 
WidgetWrap.w is now WidgetWrap._w.  You can update your code to work 
with both versions by accessing with foo._w and setting foo._w then 
calling foo._invalidate().

The reason for this change is that WidgetWrap was being used both as a 
way to compose new widgets from other widgets (ie the contained widget 
should be hidden) and as a way of creating a decoration around a widget 
by overriding only certain methods (ie the contained widget should be 
accessible.)  The former use is the intended use of WidgetWrap, so I 
have added the underscore to indicate that this is an internal value for 
the widget.  The latter use is now covered by the new WidgetDecoration 
class, which is now being used through the library.

New Stuff:

- MainLoop class and event loop classes
- 256 and 88 color support
- much better docstrings and doctests
- lots of small improvements
(Continue reading)

Permalink | Reply | 8 comments |
headers
Ian Ward | 10 Nov 2009 04:58
Favicon
Gravatar

Re: Preparing for 0.9.9

Ian Ward wrote:
> I will update the changelog with the full list shortly.

There are just a couple more small things I need to do before pushing
this out.  Here's the changelog I have so far:

    * New support for 256 and 88 color terminals with raw_display
      and html_fragment display modules

    * New palette_test example program to demonstrate high color
      modes

    * New AttrSpec class for specifying specific colors instead of
      using attributes defined in the screen's palette

    * New MainLoop class ties together widgets, user input, screen
      display and one of a number of new event loops, removing the
      need for tedious, error-prone boilerplate code

    * New GLibEventLoop allows running Urwid applications with glib

    * Added new docstrings and doctests to many widget classes

    * New AttrMap widget supports mapping any attribute to any other
      attribute, replaces AttrWrap widget

    * New WidgetDecoration base class for AttrMap, BoxAdapter, Padding
      and LineBox widgets creates a common method for accessing and
      updating the contained widgets
(Continue reading)

Permalink | Reply | 5 comments |

Gmane