Fix objects references

--HG--
branch : feature-sphinx

11 files changed, 208 insertions, 184 deletions

diff --git a/docs/manual/canvascache.rst b/docs/manual/canvascache.rst
index 83c278c..4304d31 100644
--- a/docs/manual/canvascache.rst
+++ b/docs/manual/canvascache.rst
@@ -9,9 +9,9 @@ the screen actually needs to be updated. A canvas cache is used to store
 visible, unchanged canvases so that not all of the visible widgets need to be

 rendered for each update.

 

-The :class:`Widget` base class uses some metaclass magic to capture the canvas

-objects returned when :meth:`render` is called and return them the next time

-:meth:`render` is called again with the same parameters. The

+The :class:`~urwid.widget.Widget` base class uses some metaclass magic to

+capture the canvas objects returned when :meth:`render` is called and return

+them the next time :meth:`render` is called again with the same parameters. The

 :meth:`_invalidate` method is provided as a way to remove cached widgets so

 that changes to the widget are visible the next time the screen is redrawn.

 

diff --git a/docs/manual/displayattributes.rst b/docs/manual/displayattributes.rst
index 95f94a4..e561cdb 100644
--- a/docs/manual/displayattributes.rst
+++ b/docs/manual/displayattributes.rst
@@ -23,11 +23,11 @@ You are encouraged to provide support for as many of these as you like, while
 allowing your interface to degrade gracefully by using display modules' palette

 modes and providing command line arguments or other interfaces to switch modes.

 

-When setting up a palette with :class:`MainLoop` (or directly on your screen

-instance), you may specify attributes for 16-color, monochrome and high color

-modes. You can then switch between these modes with

+When setting up a palette with :class:`~urwid.main_loop.MainLoop` (or directly

+on your screen instance), you may specify attributes for 16-color, monochrome

+and high color modes. You can then switch between these modes with

 :meth:`screen.set_terminal_properties`, where :attr:`screen` is a

-:class:`MainLoop` attribute or your own screen instance.

+:class:`~urwid.main_loop.MainLoop` attribute or your own screen instance.

 

 `register_palette reference <http://excess.org/urwid/reference.html#Screen-register_palette>`_

 

diff --git a/docs/manual/displaymodules.rst b/docs/manual/displaymodules.rst
index 0cd454c..4b7051b 100644
--- a/docs/manual/displaymodules.rst
+++ b/docs/manual/displaymodules.rst
@@ -14,14 +14,14 @@ how you plan to use Urwid.
 .. image:: images/display_modules.png

 

 Typically you will select a display module by passing it to your

-:class:`MainLoop` constructor, eg:

+:class:`~urwid.main_loop.MainLoop` constructor, eg:

 

 ::

 

     loop = MainLoop(widget, ..., screen=urwid.curses_display.Screen())

 

-If you don't specify a display module MainLoop will use

-:class:`raw_display.Screen` by default

+If you don't specify a display module, the default main loop will use

+:class:`urwid.raw_display.Screen` by default

 

 ::

 

@@ -34,20 +34,22 @@ If you don't specify a display module MainLoop will use
 

 Urwid has two display modules for displaying to terminals or the console.

 

-The :mod:`raw_display` module is a pure-python display module with no external

-dependencies. It sends and interprets terminal escape sequences directly. This

-is the default display module used by :class:`MainLoop`.

+The :mod:`urwid.raw_display` module is a pure-python display module with no

+external dependencies. It sends and interprets terminal escape sequences

+directly. This is the default display module used by

+:class:`~urwid.main_loop.MainLoop`.

 

 .. TODO: add a link to some ncurses resources?

 

-The :mod:`curses_display` module uses the curses or ncurses library provided by

-the operating system. The library does some optimization of screen updates and

-uses termcap to adjust to the user's terminal.

+The :mod:`urwid.curses_display` module uses the curses or ncurses library

+provided by the operating system. The library does some optimization of screen

+updates and uses termcap to adjust to the user's terminal.

 

 The (n)curses library will disable colors if it detects a monochrome terminal,

 so a separate set of attributes should be given for monochrome mode when

-registering a palette with :mod:`curses_display`. High colors will not be used

-by the :mod:`curses_dislpay` module. See :ref:`setting-a-palette` below.

+registering a palette with :mod:`urwid.curses_display`. High colors will not be

+used by the :mod:`urwid.curses_dislpay` module. See :ref:`setting-a-palette`

+below.

 

 This table summarizes the differences between the two modules:

 

@@ -77,8 +79,8 @@ external event loop support    YES         no
 AJAX-based Web Display Module ``web_display``

 =============================================

 

-The :mod:`web_display` module lets you run your application as a CGI script

-under Apache instead of running it in a terminal.

+The :mod:`urwid.web_display` module lets you run your application as a CGI

+script under Apache instead of running it in a terminal.

 

 This module is a proof of concept. There are security and responsiveness issues

 that need to be resolved before this module is recommended for production use.

@@ -120,7 +122,7 @@ The `example screenshots`_ are generated with this display module.
 Setting a Palette

 =================

 

-The :class:`MainLoop` constructor takes a ``palette`` parameter that it passes

+The :class:`~urwid.main_loop.MainLoop` constructor takes a ``palette`` parameter that it passes

 to the :meth:`register_palette` method of your display module.

 

 A palette is a list of palette entry names, called "attributes" and foreground

diff --git a/docs/manual/eventloops.rst b/docs/manual/eventloops.rst
index 2e388a9..f684c0f 100644
--- a/docs/manual/eventloops.rst
+++ b/docs/manual/eventloops.rst
@@ -4,13 +4,14 @@
   Event Loops  

 ***************

 

-Urwid's event loop classes handle waiting for things for the :class:`MainLoop`. The

-different event loops allow you to integrate with Twisted_ or Glib_ libraries, or

-use a simple *select*-based loop. Event loop classes abstract the particulars

-of waiting for input and calling functions as a result of timeouts.

+Urwid's event loop classes handle waiting for things for the

+:class:`~urwid.main_loop.MainLoop`. The different event loops allow you to

+integrate with Twisted_ or Glib_ libraries, or use a simple *select*-based

+loop. Event loop classes abstract the particulars of waiting for input and

+calling functions as a result of timeouts.

 

 You will typically only have a single event loop in your application, even if

-you have more than one :class:`MainLoop` running.

+you have more than one :class:`~urwid.main_loop.MainLoop` running.

 

 You can add your own files to watch to your event loop, with the

 :meth:`watch_file` method. Using this interface gives you the special handling

@@ -23,7 +24,7 @@ of :exc:`ExitMainLoop` and other exceptions when using Glib_ or Twisted_.
 ===================

 

 This event loop is based on ``select.select()``. This is the default event loop

-created if none is passed to :class:`MainLoop`.

+created if none is passed to :class:`~urwid.main_loop.MainLoop`.

 

 ::

 

@@ -36,9 +37,10 @@ created if none is passed to :class:`MainLoop`.
 ====================

 

 This event loop uses Twisted's reactor. It has been set up to emulate

-:class:`SelectEventLoop`'s behaviour and will start the reactor and stop it on

-an error. This is not the standard way of using Twisted's reactor, so you may

-need to modify this behaviour for your application.

+:class:`~urwid.main_loop.SelectEventLoop`'s behaviour and will start the

+reactor and stop it on an error. This is not the standard way of using

+Twisted's reactor, so you may need to modify this behaviour for your

+application.

 

 ::

 

diff --git a/docs/manual/index.rst b/docs/manual/index.rst
index 6295dec..0b356a5 100644
--- a/docs/manual/index.rst
+++ b/docs/manual/index.rst
@@ -43,11 +43,11 @@ are supported by all terminals, so Urwid helps you write applications that
 support different color modes depending on what the user's terminal supports
 and what they choose to enable.
 
-The :class:`ListBox` is one of Urwid's most powerful widgets, and you may
-control of the :ref:`listbox contents <listbox-contents>` by using a built-in
-list walker class or by writing one yourself. This is very useful for scrolling
-through lists of any significant length, or with nesting, folding and other
-similar features.
+The :class:`~urwid.listbox.ListBox` is one of Urwid's most powerful widgets,
+and you may control of the :ref:`listbox contents <listbox-contents>` by using
+a built-in list walker class or by writing one yourself. This is very useful
+for scrolling through lists of any significant length, or with nesting, folding
+and other similar features.
 
 When a widget renders a canvas to be drawn on screen, a weak reference to it is
 stored in the :ref:`canvas cache <canvas-cache>`. This cache is used any time a
diff --git a/docs/manual/listboxcontents.rst b/docs/manual/listboxcontents.rst
index 87f855e..aae4667 100644
--- a/docs/manual/listboxcontents.rst
+++ b/docs/manual/listboxcontents.rst
@@ -4,19 +4,20 @@
   ``ListBox`` Contents  

 ************************

 

-The :class:`ListBox` is a box widget that contains flow widgets. Its contents

-are displayed stacked vertically, and the :class:`ListBox` allows the user to

-scroll through its content. One of the flow widgets displayed in the

-:class:`ListBox` is its focus widget.

+The :class:`~urwid.listbox.ListBox` is a box widget that contains flow widgets.

+Its contents are displayed stacked vertically, and the

+:class:`~urwid.listbox.ListBox` allows the user to scroll through its content.

+One of the flow widgets displayed in the :class:`~urwid.listbox.ListBox` is its

+focus widget.

 

 List Walkers

 ============

 

-The :class:`ListBox` does not manage the widgets it displays directly, instead

-it passes that task to a class called a "list walker". List walkers keep track

-of the widget in focus and provide an opaque position object that the

-:class:`ListBox` may use to iterate through widgets above and below the focus

-widget.

+The :class:`~urwid.listbox.ListBox` does not manage the widgets it displays

+directly, instead it passes that task to a class called a "list walker". List

+walkers keep track of the widget in focus and provide an opaque position object

+that the :class:`~urwid.listbox.ListBox` may use to iterate through widgets

+above and below the focus widget.

 

 A `SimpleListWalker <http://excess.org/urwid/reference.html#SimpleListWalker>`_

 is a list walker that behaves like a normal Python list. It may be used any

@@ -27,7 +28,7 @@ list walker that manages creating widgets as they are requested and destroying
 them later to avoid excessive memory use.

 

 List walkers may also be used to display tree or other structures within a

-:class:`ListBox`. A number of the `example programs

+:class:`~urwid.listbox.ListBox`. A number of the `example programs

 <http://excess.org/urwid/examples.html#>`_ demonstrate the use of custom list

 walker classes.

 

@@ -37,37 +38,40 @@ walker classes.
 Focus & Scrolling Behavior

 ==========================

 

-The :class:`ListBox` passes all key presses it receives first to its focus

-widget. If its focus widget does not handle a keypress then the

-:class:`ListBox` may handle the keypress by scrolling and/or selecting another

-widget to become its new focus widget.

+The :class:`~urwid.listbox.ListBox` passes all key presses it receives first to

+its focus widget. If its focus widget does not handle a keypress then the

+:class:`~urwid.listbox.ListBox` may handle the keypress by scrolling and/or

+selecting another widget to become its new focus widget.

 

-The :class:`ListBox` tries to do *the most sensible thing* when scrolling and

-changing focus. When the widgets displayed are all :class:`Text` widgets or

-other unselectable widgets then the :class:`ListBox` will behave like a web

-browser does when the user presses *UP*, *DOWN*, *PAGE UP* and *PAGE DOWN*: new

-text is immediately scrolled in from the top or bottom. The :class:`ListBox`

-chooses one of the visible widgets as its focus widget when scrolling. When

-scrolling up the :class:`ListBox` chooses the topmost widget as the focus, and

-when scrolling down the :class:`ListBox` chooses the bottommost widget as the

-focus.

+The :class:`~urwid.listbox.ListBox` tries to do *the most sensible thing* when

+scrolling and changing focus. When the widgets displayed are all

+:class:`~urwid.widget.Text` widgets or other unselectable widgets then the

+:class:`~urwid.listbox.ListBox` will behave like a web browser does when the

+user presses *UP*, *DOWN*, *PAGE UP* and *PAGE DOWN*: new text is immediately

+scrolled in from the top or bottom. The :class:`~urwid.listbox.ListBox` chooses

+one of the visible widgets as its focus widget when scrolling. When scrolling

+up the :class:`~urwid.listbox.ListBox` chooses the topmost widget as the focus,

+and when scrolling down the :class:`~urwid.listbox.ListBox` chooses the

+bottommost widget as the focus.

 

-The :class:`ListBox` remembers the visible location of its focus widget as

-either an "offset" or an "inset". An offset is the number of rows between the

-top of the :class:`ListBox` and the beginning of the focus widget. An offset

-of zero corresponds to a widget with its top aligned with the top of the

-:class:`ListBox`. An inset is the fraction of rows of the focus widget that

-are "above" the top of the :class:`ListBox` and not visible. The

-:class:`ListBox` uses this method of remembering the focus widget location so

-that when the :class:`ListBox` is resized the the text will remain roughly in

-the same position of the visible area.

+The :class:`~urwid.listbox.ListBox` remembers the visible location of its focus

+widget as either an "offset" or an "inset". An offset is the number of rows

+between the top of the :class:`~urwid.listbox.ListBox` and the beginning of the

+focus widget. An offset of zero corresponds to a widget with its top aligned

+with the top of the :class:`~urwid.listbox.ListBox`. An inset is the fraction

+of rows of the focus widget that are "above" the top of the

+:class:`~urwid.listbox.ListBox` and not visible. The

+:class:`~urwid.listbox.ListBox` uses this method of remembering the focus

+widget location so that when the :class:`~urwid.listbox.ListBox` is resized the

+the text will remain roughly in the same position of the visible area.

 

-When there are selectable widgets visible in the :class:`ListBox` the focus

-will move between the selectable widgets, skipping the unselectable widgets.

-The :class:`ListBox` will try to scroll all the rows of a selectable widget

-into view so that the user can see the new focus widget in its entirety. This

-behavior can be used to bring more than a single widget into view by using a

-:class:`Pile` or other container widget to combine a selectable widget with

-other widgets that should be visible at the same time.

+When there are selectable widgets visible in the

+:class:`~urwid.listbox.ListBox` the focus will move between the selectable

+widgets, skipping the unselectable widgets.  The

+:class:`~urwid.listbox.ListBox` will try to scroll all the rows of a selectable

+widget into view so that the user can see the new focus widget in its entirety.

+This behavior can be used to bring more than a single widget into view by using

+a :class:`~urwid.container.Pile` or other container widget to combine a

+selectable widget with other widgets that should be visible at the same time.

 

 `Tutorial chapters covering ListBox usage <http://excess.org/urwid/tutorial.html#frlb>`_

diff --git a/docs/manual/mainloop.rst b/docs/manual/mainloop.rst
index 0d6465f..c65a9e9 100644
--- a/docs/manual/mainloop.rst
+++ b/docs/manual/mainloop.rst
@@ -4,42 +4,48 @@
   Main loop  

 *************

 

-The :class:`MainLoop` class ties together a :ref:`display-modules`, a set of

-widgets and an :ref:`event-loops`. It handles passing input from the display

-module to the widgets, rendering the widgets and passing the rendered canvas to

-the display module to be drawn.

+The :class:`~urwid.main_loop.MainLoop` class ties together a :ref:`display

+module <display-modules>`, a set of widgets and an :ref:`event loop

+<event-loops>`. It handles passing input from the display module to the

+widgets, rendering the widgets and passing the rendered canvas to the display

+module to be drawn.

 

 You may filter the user's input before it is passed to the widgets with your

-own code by using :func:`input_filter`, or have special code to handle input

-not handled by the widgets by using :func:`unhandled_input`.

-

-You may set alarms to create timed events using :func:`set_alarm_at` or

-:func:`set_alarm_in`. These methods automatically add a call to

-:func:`draw_screen` after calling your callback. :func:`remove_alarm` may be

-used to remove alarms.

-

-When the main loop is running, any code that raises an :exc:`ExitMainLoop`

-exception will cause the loop to exit cleanly. If any other exception reaches

-the main loop code, it will shut down the screen to avoid leaving the terminal

-in an unusual state then re-raise the exception for normal handling.

-

-Using :class:`MainLoop` is highly recommended, but if it does not fit the needs

-of your application you may choose to use your own code instead. There are no

-dependencies on :class:`MainLoop` in other parts of Urwid.

-

-`MainLoop reference <http://excess.org/urwid/reference.html#MainLoop>`_

+own code by using :func:`input_filter() <urwid.main_loop.MainLoop>`, or have

+special code to handle input not handled by the widgets by using

+:func:`unhandled_input() <urwid.main_loop.MainLoop>`.

+

+You may set alarms to create timed events using

+:meth:`~urwid.main_loop.MainLoop.set_alarm_at` or

+:meth:`~urwid.main_loop.MainLoop.set_alarm_in`. These methods automatically add

+a call to :func:`~urwid.main_loop.MainLoop.draw_screen` after calling your

+callback. :meth:`~urwid.main_loop.MainLoop.remove_alarm` may be used to remove

+alarms.

+

+When the main loop is running, any code that raises an

+:exc:`~urwid.main_loop.ExitMainLoop` exception will cause the loop to

+exit cleanly. If any other exception reaches the main loop code, it will shut

+down the screen to avoid leaving the terminal in an unusual state then re-raise

+the exception for normal handling.

+

+Using :class:`~urwid.main_loop.MainLoop` is highly recommended, but if it does

+not fit the needs of your application you may choose to use your own code

+instead. There are no dependencies on :class:`~urwid.main_loop.MainLoop` in

+other parts of Urwid.

 

 Widgets Displayed

 =================

 

-The topmost widget displayed by :class:`MainLoop` must be passed as the first

-parameter to the constructor. If you want to change the topmost widget while

-running, you can assign a new widget to the `MainLoop` object's :attr:`widget`

-attribute. This is useful for applications that have a number of different

-modes or views.

+The topmost widget displayed by :class:`~urwid.main_loop.MainLoop` must be

+passed as the first parameter to the constructor. If you want to change the

+topmost widget while running, you can assign a new widget to the

+:class:`~urwid.main_loop.MainLoop` object's

+:attr:`~urwid.main_loop.MainLoop.widget` attribute. This is useful for

+applications that have a number of different modes or views.

 

 The displayed widgets will be handling user input, so it is better to extend

 the widgets that are displayed with your application-specific input handling so

 that the application's behaviour changes when the widgets change. If all your

-custom input handling is done from :func:`unhandled_input`, it will be

-difficult to extend as your application gets more complicated. 

+custom input handling is done from :func:`unhandled_input()

+<urwid.main_loop.MainLoop>`, it will be difficult to extend as your application

+gets more complicated. 

diff --git a/docs/manual/textattributes.rst b/docs/manual/textattributes.rst
index cf59141..899b681 100644
--- a/docs/manual/textattributes.rst
+++ b/docs/manual/textattributes.rst
@@ -4,10 +4,10 @@
   Text Attributes  

 *******************

 

-A :class:`Text` widget can take plain or unicode strings, but you can also

-specify which attributes to display each part of that text by using "text

-markup" format. Text markup made up of lists and tuples. Tuples contain an

-attribute and text markup to apply it to. Lists used to concatenate text

+A :class:`~urwid.widget.Text` widget can take plain or unicode strings, but you

+can also specify which attributes to display each part of that text by using

+"text markup" format. Text markup made up of lists and tuples. Tuples contain

+an attribute and text markup to apply it to. Lists used to concatenate text

 markup.

 

 The normal text formatting rules apply and the attributes will follow the text

@@ -30,9 +30,9 @@ The string will appear with foreground and backgrounds specified in the display
 module's palette for ``'attr1'``, but the space around (before/after) the text

 will appear with the default foreground and background.

 

-If you want the whole :class:`Text` widget, including the space around the

-text, to appear as a single attribute you should put your widget inside an

-:class:`AttrMap` widget.

+If you want the whole :class:`~urwid.widget.Text` widget, including the space

+around the text, to appear as a single attribute you should put your widget

+inside an :class:`~urwid.decoration.AttrMap` widget.

 

 `AttrMap reference <http://excess.org/urwid/reference.html#AttrMap>`_

 

diff --git a/docs/manual/textlayout.rst b/docs/manual/textlayout.rst
index cd7ae37..bbca25d 100644
--- a/docs/manual/textlayout.rst
+++ b/docs/manual/textlayout.rst
@@ -5,9 +5,9 @@
 ***************

 

 Mapping a text string to screen coordinates within a widget is called text

-layout. The :class:`Text` widget's default layout class supports aligning text

-to the left, center or right, and can wrap text on space characters, at any

-location, or clip text that is off the edge.

+layout. The :class:`~urwid.widget.Text` widget's default layout class supports

+aligning text to the left, center or right, and can wrap text on space

+characters, at any location, or clip text that is off the edge.

 

 `Text widget reference <http://excess.org/urwid/reference.html#Text>`_

 

@@ -82,10 +82,10 @@ Text Layout Structures
 The mapping from a text string to where that text will be displayed in the

 widget is expressed as a text layout structure.

 

-Text layout structures are used both for rendering :class:`Text` widgets and

-for mapping ``(x, y)`` positions within a widget back to the corresponding

-offsets in the text. The latter is used when moving the cursor in :class:`Edit`

-widgets up and down or by clicking with the mouse.

+Text layout structures are used both for rendering :class:`~urwid.widget.Text`

+widgets and for mapping ``(x, y)`` positions within a widget back to the

+corresponding offsets in the text. The latter is used when moving the cursor in

+:class:`~urwid.widget.Edit` widgets up and down or by clicking with the mouse.

 

 A text layout structure is a list of one or more line layouts. Each line layout

 corresponds to a row of text in the widget, starting from its top.

@@ -97,17 +97,17 @@ A. ``(column width, starting text offset, ending text offset)``
 B. ``(column width of space characters to insert, text offset or None)``

 C. ``(column width, text offset, "new text to insert")``

 

-Tuple A displays a segment of text from the :class:`Text` widget. Column width

-is explicitly specified because some characters within the text may be zero

-width or double width.

+Tuple A displays a segment of text from the :class:`~urwid.widget.Text` widget.

+Column width is explicitly specified because some characters within the text

+may be zero width or double width.

 

 Tuple B inserts any number of space characters, and if those characters

 correspond to an offset within the text, that may be specified.

 

 Tuple C allows insertion of arbitrary text. This could be used for hyphenating

 split words or any other effect not covered by A or B. The

-:class:`StandardTextLayout` does not currently use this tuple in its line

-layouts.

+:class:`~urwid.text_layout.StandardTextLayout` does not currently use this

+tuple in its line layouts.

 

 `TextLayout reference <http://excess.org/urwid/reference.html#TextLayout>`_

 

@@ -123,12 +123,13 @@ layouts.
 Custom Text Layouts

 ===================

 

-The :class:`StandardTextLayout` is set as the class variable

-:attr:`Text.layout`. Individual :class:`Text` widgets may use a different

-layout class, or you can change the default by setting the :attr:`Text.layout`

-class variable itself.

+The :class:`~urwid.text_layout.StandardTextLayout` is set as the class variable

+:attr:`~urwid.widget.Text.layout`. Individual :class:`~urwid.widget.Text`

+widgets may use a different layout class, or you can change the default by

+setting the :attr:`~urwid.widget.Text.layout` class variable itself.

 

-A custom text layout class should extend the :class:`TextLayout` base class and

-return text layout structures from its :meth:`layout` method (see above).

+A custom text layout class should extend the

+:class:`~urwid.text_layout.TextLayout` base class and return text layout

+structures from its :meth:`layout` method (see above).

 

 `TextLayout reference <http://excess.org/urwid/reference.html#TextLayout>`_

diff --git a/docs/manual/userinput.rst b/docs/manual/userinput.rst
index dc41ca9..17767be 100644
--- a/docs/manual/userinput.rst
+++ b/docs/manual/userinput.rst
@@ -10,12 +10,13 @@ All input from the user is parsed by a display module, and returned from either
 the :meth:`get_input` or :meth:`get_input_nonblocking` methods as a list.

 Window resize events are also included in the user input.

 

-The :class:`MainLoop` class will take this input and pass each item to the

-widget methods :meth:`keypress` or :meth:`mouse_event`. You may filter input

-(possibly removing or altering it) before it is passed to the widgets, or can

-catch unhandled input by passing functions into the :class:`MainLoop`

-constructor. If the window was resized :class:`MainLoop` will query the new

-display size and update the screen.

+The :class:`~urwid.main_loop.MainLoop` class will take this input and pass each

+item to the widget methods :meth:`keypress` or :meth:`mouse_event`. You may

+filter input (possibly removing or altering it) before it is passed to the

+widgets, or can catch unhandled input by passing functions into the

+:class:`~urwid.main_loop.MainLoop` constructor. If the window was resized

+:class:`~urwid.main_loop.MainLoop` will query the new display size and update

+the screen.

 

 There may be more than one keystroke or mouse event processed at a time, and

 each is sent as a separate item in the list.

diff --git a/docs/manual/widgetmethods.rst b/docs/manual/widgetmethods.rst
index 2b04f3c..584c1ae 100644
--- a/docs/manual/widgetmethods.rst
+++ b/docs/manual/widgetmethods.rst
@@ -7,11 +7,13 @@
 Widgets in Urwid are easiest to create by extending other widgets. If you are

 making a new type of widget that can use other widgets to display its content,

 like a new type of button or control, then you should start by extending

-:class:`WidgetWrap` and passing the display widget to its constructor.

+:class:`~urwid.widget.WidgetWrap` and passing the display widget to its

+constructor.

 

-This section describes the :class:`Widget` interface in detail and is useful if

-you're looking to modify the behavior of an existing widget, build a new widget

-class from scratch or just want a better understanding of the library.

+This section describes the :class:`~urwid.widget.Widget` interface in detail

+and is useful if you're looking to modify the behavior of an existing widget,

+build a new widget class from scratch or just want a better understanding of

+the library.

 

 One design choice that stands out is that widgets in Urwid typically have no

 size. Widgets don't store the size they will be displayed at, and instead are

@@ -34,16 +36,16 @@ It also has disadvantages:
 * duplicated size calculations across methods

 

 For determining a widget's size on screen it is possible to look up the size(s)

-it was rendered at in the :class:`CanvasCache`. There are plans to address some

-of the duplicated size handling code in the container widgets in a future Urwid

-release.

+it was rendered at in the :class:`~urwid.canvas.CanvasCache`. There are plans

+to address some of the duplicated size handling code in the container widgets

+in a future Urwid release.

 

 The same holds true for a widget's focus state, so that too is passed in to

 functions that need it.

 

-The :class:`Widget` base class has some metaclass magic that creates a

-:attr:`__super` attribute for calling your superclass: :attr:`self.__super` is

-the same as the usual ``super(MyClassName, self)``.

+The :class:`~urwid.widget.Widget` base class has some metaclass magic that

+creates a :attr:`__super` attribute for calling your superclass:

+:attr:`self.__super` is the same as the usual ``super(MyClassName, self)``.

 

 .. TODO: what to do with these references?

 

@@ -58,13 +60,14 @@ the same as the usual ``super(MyClassName, self)``.
       Return a set of the sizing modes this widget supports, one or more of

       *FLOW*, *BOX* or *FIXED*.

 

-      The :class:`Widget` base class defines this method as ``return

-      self._sizing``, so if your widget's sizing modes never change you can

-      define :attr:`_sizing` in your class definition, and not bother

-      overriding this method.

+      The :class:`~urwid.widget.Widget` base class defines this method as

+      ``return self._sizing``, so if your widget's sizing modes never change

+      you can define :attr:`~urwid.widget.Widget._sizing` in your class

+      definition, and not bother overriding this method.

 

-      If you inherit from :class:`FlowWidget`, :class:`BoxWidget` or

-      :class:`FixedWidget`, :attr:`_sizing` is already defined for you as

+      If you inherit from :class:`~urwid.widget.FlowWidget`,

+      :class:`~urwid.widget.BoxWidget` or :class:`~urwid.widget.FixedWidget`,

+      :attr:`~urwid.widget.Widget._sizing` is already defined for you as

       ``set([FLOW])``, ``set([BOX])`` or ``set([FIXED])``, respectively.

 

       If *FLOW* is among the values returned then your other methods must be

@@ -86,21 +89,24 @@ the same as the usual ``super(MyClassName, self)``.
 

    .. method:: render(size, focus=False)

 

-      Render the widget content and return it as a :class:`Canvas` subclass.

-      :class:`Text` widgets return a :class:`TextCanvas` (arbitrary text and

-      attributes), :class:`SolidFill` widgets return a :class:`SolidCanvas` (a

-      single character repeated across the whole surface) and container widgets

-      return a :class:`CompositeCanvas` (one or more other canvases arranged

-      arbitrarily).

+      Render the widget content and return it as a

+      :class:`~urwid.canvas.Canvas` subclass.  :class:`~urwid.widget.Text`

+      widgets return a :class:`~urwid.canvas.TextCanvas` (arbitrary text and

+      attributes), :class:`~urwid.canvas.SolidFill` widgets return a

+      :class:`~urwid.canvas.SolidCanvas` (a single character repeated across

+      the whole surface) and container widgets return a

+      :class:`~urwid.canvas.CompositeCanvas` (one or more other canvases

+      arranged arbitrarily).

 

       If *focus* is ``False``, the returned canvas may not have a cursor

       position set.

 

       There is some metaclass magic in the Widget base class that causes the

-      result of this method to be cached by :class:`CanvasCache`, and later

-      calls will automatically look up the value in the cache first. The class

-      variable :attr:`ignore_focus` may be defined and set to ``True`` if this

-      widget renders the same regardless of the value of the *focus* parameter.

+      result of this method to be cached by :class:`~urwid.canvas.CanvasCache`,

+      and later calls will automatically look up the value in the cache first.

+      The class variable :attr:`ignore_focus` may be defined and set to

+      ``True`` if this widget renders the same regardless of the value of the

+      *focus* parameter.

 

       Any time the content of your widget changes you must call

       :meth:`_invalidate` to remove any cached canvases, or your widget may not

@@ -111,11 +117,11 @@ the same as the usual ``super(MyClassName, self)``.
       Return ``True`` if this is a widget that is designed to take the focus,

       ``False`` otherwise.

 

-      The :class:`Widget` base class defines this method as ``return

-      self._selectable`` and :attr:`_selectable` is defined as ``False``, so

-      you may do nothing if your widget is not selectable, or if your widget is

-      always selectable just set your :attr:`_selectable` class variable to

-      ``True``.

+      The :class:`~urwid.widget.Widget` base class defines this method as

+      ``return self._selectable`` and :attr:`_selectable` is defined as

+      ``False``, so you may do nothing if your widget is not selectable, or if

+      your widget is always selectable just set your :attr:`_selectable` class

+      variable to ``True``.

       

       If this method returns ``True`` then the :meth:`keypress` method must be

       implemented.

@@ -136,12 +142,13 @@ the same as the usual ``super(MyClassName, self)``.
       operation. If your implementation may take a long time you should add

       your own caching here.

       

-      There is some metaclass magic in the :class:`Widget` base class that

-      causes the result of this function to be computed from any canvas cached

-      by :class:`CanvasCache`, so if your widget has been rendered you may not

-      receive calls to this function. The class variable :attr:`ignore_focus`

-      may be defined and set to ``True`` if this widget renders the same size

-      regardless of the value of the *focus* parameter.

+      There is some metaclass magic in the :class:`~urwid.widget.Widget` base

+      class that causes the result of this function to be computed from any

+      canvas cached by :class:`~urwid.canvas.CanvasCache`, so if your widget

+      has been rendered you may not receive calls to this function. The class

+      variable :attr:`ignore_focus` may be defined and set to ``True`` if this

+      widget renders the same size regardless of the value of the *focus*

+      parameter.

 

    .. method:: pack(size, focus=False)

 

@@ -150,15 +157,16 @@ the same as the usual ``super(MyClassName, self)``.
       implement this method and return their size when ``()`` is passed as the

       *size* parameter.

       

-      The :class:`Widget` base class definition of this method returns the

-      *size* passed, or the *maxcol* passed and the value of :meth:`rows` as

-      the *maxrow* when ``(maxcol,)`` is passed as the *size* parameter.

+      The :class:`~urwid.widget.Widget` base class definition of this method

+      returns the *size* passed, or the *maxcol* passed and the value of

+      :meth:`rows` as the *maxrow* when ``(maxcol,)`` is passed as the *size*

+      parameter.

       

       This is a new method that hasn't been fully implemented across the

       standard widget types. In particular it has not yet been implemented for

       container widgets.

       

-      :class:`Text` widgets `have implemented this method

+      :class:`~urwid.widget.Text` widgets `have implemented this method

       <http://excess.org/urwid/reference.html#Text-pack>`_. You can use

       :meth:`pack` to calculate the minumum columns and rows required to

       display a text widget without wrapping, or call it iteratively to

@@ -195,10 +203,10 @@ the same as the usual ``super(MyClassName, self)``.
 

       Return the cursor coordinates ``(col, row)`` of a cursor that will appear

       as part of the canvas rendered by this widget when in focus, or ``None``

-      if no cursor is displayed. The :class:`ListBox` widget uses this method

-      to make sure a cursor in the focus widget is not scrolled out of view.

-      It is a separate method to avoid having to render the whole widget while

-      calculating layout.

+      if no cursor is displayed. The :class:`~urwid.listbox.ListBox` widget

+      uses this method to make sure a cursor in the focus widget is not

+      scrolled out of view.  It is a separate method to avoid having to render

+      the whole widget while calculating layout.

       

       Container widgets will typically call the :meth:`get_cursor_coords`

       method on their focus widget.

@@ -209,11 +217,11 @@ the same as the usual ``super(MyClassName, self)``.
       widget. This value might not be the same as the column returned from

       :meth:`get_cursor_coords`.

       

-      The :class:`ListBox` and :class:`Pile` widgets call this method on a

-      widget losing focus and use the value returned to call

-      :meth:`move_cursor_to_coords` on the widget becoming the focus. This

-      allows the focus to move up and down through widgets while keeping the

-      cursor in approximately the same column on screen.

+      The :class:`~urwid.listbox.ListBox` and :class:`~urwid.container.Pile`

+      widgets call this method on a widget losing focus and use the value

+      returned to call :meth:`move_cursor_to_coords` on the widget becoming the

+      focus. This allows the focus to move up and down through widgets while

+      keeping the cursor in approximately the same column on screen.

 

    .. method:: move_cursor_to_coords(size, col, row)