Andrew Kuchling <akuchlin@mems-exchange.org> writes:
> [CC'ing Thomas Gellekum <tg@melaten.rwth-aachen.de>]
>
> On Wed, Dec 13, 2000 at 01:24:01AM -0500, Fred L. Drake, Jr. wrote:
> > Would it be reasonable to add panel support as a second extension
> >module? Is there really a need for them to be in the same module,
> >since the panel library is a separate library?
>
> Quite possibly, though the patch isn't structured that way. The panel
> module will need access to the type object for the curses window
> object, so it'll have to ensure that _curses is already imported, but
> that's no problem.
You mean as separate modules like
import curses
import panel
? Hm. A panel object is associated with a window object, so it's
created from a window method. This means you'd need to add
window.new_panel() to PyCursesWindow_Methods[] and
curses.update_panels(), curses.panel_above() and curses.panel_below()
(or whatever they're called after we're through discussing this ;-))
to PyCurses_Methods[].
Also, the curses.panel_{above,below}() wrappers need access to the
list_of_panels via find_po().
> Thomas, do you feel capable of implementing it as a separate module,
> or should I work on it?
It's probably finished a lot sooner when you do it; OTOH, it would be
fun to try it. Let's carry this discussion a bit further.
> Probably a _cursesmodule.h header will have
> to be created to make various definitions available to external
> users of the basic objects in _curses.
That's easy. The problem is that we want to extend those basic objects
in _curses.
> (Bonus: this means that the
> menu and form libraries, if they ever get wrapped, can be separate
> modules, too.)
Sure, if we solve this for panel, the others are a SMOP. :-)
tg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4