[Tkinter-discuss] Hooking into custom Tcl/Tk Widgets fromTkinter (vis)

[Fredrik Lundh]

"David King" <dking at nrao.edu> skrev i meddelandet news:4284C4A0.4030705 at nrao.edu...
> Thank you, Jeff, for your suggested code to send Tkinter's interpreter
> pointer into C++; along with Mr. Lundh's advice, you are helping me to piece
> together what I need to make my custom C++/Tk widget available in Tkinter.
>
> I still would like to hear from someone on how I'd invoke creation of my new
> custom widget and send it commands from python.  The C++ code registers
> callbacks for both these sorts of things with the Tcl interpreter, so that
> they become available as _Tcl/Tk_ commands.  But how can such commands be
> sent from python to Tkinter's Tcl/Tk interpreter?
>
> ------
>
>
> At the risk of putting too many questions in one email, I'll also mention
> the other main problem I'm wrestling with.  I need to understand the
> 'interactive' aspects of Tkinter--i.e., how _both_ the Tkinter gui(s) and
> python's sommand-line interpreter can remain 'live' at the same time, each
> responding to its own type of input.  I need my user to ba able to send
> commands to my widget via python commands as well as via gui input.  I know
> that matplotlib (esp. on top of Tkinter, and operated from the IPython
> shell) manages to do this, and the matplotlib folks seem to think Tkinter
> even has advantages over other widgetsets such as GTK for interactive use.
> In the most elementary Tkinter examples I run, however, I must give up all
> further python input when I enter tk.mainloop().
>
> IPython/matplotlib give hints that perhaps they manage the trick by creating
> a second thread for the Tkinter loop to run in.  That may be an ok solution,
> if I can truly understand where/how the one-thread-at-a-time-only locks need
> to be used (apparently both the python and Tcl interpreters each need such
> exclusivity; my widget library code will certainly need it as well).
>
> Alternatively,... is there perhaps another way of merging the console and
> gui-event input streams, _without_ using more than one process/thread?
>
> All suggestions welcome.  (Is there a 'bible' that lays all this out?  I'm
> willing to spring for the book if necessary).
>
> David King
>
>
>
>
> Jeff Epler wrote:
> > On Fri, Apr 29, 2005 at 11:01:15AM -0600, David King wrote:
> >
> >>But let's leave WCK aside and just talk about plain Tkinter for the moment.
> >> I'd like to understand how my custom C++/Tk widget could make itself known
> >>in the usual Tkinter world.  On the C++ side, essentially all my Tcl/Tk API
> >>calls interact with a tcl interpreter handle ('Tcl_Interp*').  Presumably I
> >>need to get the one Tkinter uses, instead of creating an interpreter myself
> >>(and also to let Tkinter handle the event loop, rather than doing _that_
> >>myself).  I'm wondering how I get this handle from Tkinter.
> >
> >
> > Here is some "C" code that I have used for this purpose.
> >
> > // this code is in the public domain
> > static Tcl_Interp *get_interpreter(PyObject *tkapp) {
> >     long interpaddr;
> >     PyObject *interpaddrobj = PyObject_CallMethod(tkapp, "interpaddr", NULL);
> >     if(interpaddrobj == NULL) { return NULL; }
> >     interpaddr = PyInt_AsLong(interpaddrobj);
> >     Py_DECREF(interpaddrobj);
> >     if(interpaddr == -1) { return NULL; }
> >     return (Tcl_Interp*)interpaddr;
> > }
> >
> > 'PyObject *tkapp' is the thing returned by _tkinter.create(), and available as
> > the 'tk' attribute on all Tkinter widgets.
> >
> > This is not foolproof, because passing in an object like
> >     class K:
> >         interpaddr = 0
> > will soon lead to a crash.  But if you can trust the calling code to only pass in
> > "real" interpreters, it should work just fine.
> >
> > Jeff