Tcl/Tk clipboard under Windows

[Cameron Laird]

Procedural question for Scriptics employees and other interested
parties:  how should information flow from Tk's client kingdoms
(I know it's actively used by programmers in C, Perl, Python, Lua,
Rexx, Scheme, ...) back to the metropolitan core?  My personal
view is that the bug-tracking mechanism now in place is a bit
clumsy for the comp.lang.tcl crowd.  Whether you agree with me on
that or not, I'll strenuously argue that it's definitely not a
good match for our friends from comp.lang.perl.tk, comp.lang.python,
and elsewhere.  At the very least, they need guides and a
translation service so they have a sense of how to behave "when in
Rome".  Anyone have advice?

Here's a concrete instance where we can experiment.  In article
<1284363528-1226883 at hypernet.com>, Gordon McMillan <gmcm at hypernet.com>
observes:
>Michael S. Schliephake writes:
>
>> (Win-NT 4, W98 - Python 1.5.2, Tk 8.05)
>> If you copy some text from a Tkinter-prog to the clipboard and the
>> program is finished immediately, one cannot paste the clipboard
>> content into another programm. If you paste before finishing the
>> Python-program, the clipboard content is how intended and remains
>> there.
>> 
>> The problem seems to be in the Tcl/Tk implementation because Tcl/Tk
>> standalone behaves in the same way. Has anyone enough knowledge of
>> the Tk-implementation to help with a correction?
>
>Did a quick grep of T8.0, but I didn't catch them red-handed.
>However, it is generally considered polite to delete stuff you've
>put on the clipboard. Reason - you've allocated Windows (not
>application) memory for the data. If you don't deallocate it, it may
>sit around for ages. Not significant for a few lines of text, but
>perhaps the data is a 24 bit color DIB. 
			.
			.
			.
Since then, the c.l.p Tkinterites have developed a patch (to Tk)
that looks to me like something Scriptics (and Jan?) should very much
want to have in the core.  What should happen to the patch?  It's not
practical to discuss it in c.l.t, 'cause a critical mass of
Tkinterites won't pick it up there.

More background:  a few of us have seen the difficulties experienced
by the dedicated volunteers of CPAN, Python's starship, the balkanized
Tcl archives, Trove, the Eiffel repositories, ..., and have proceeded
directly to the fantasy of compounding these challenges by
constructing a *cross-language* collaboration facility.  Mr.
Schliephake's patch presents a provocative challenge to existing
habits of solution.  Can we better address it by solving a more
general problem?

I'd be gratified even by a crisp statement from Scriptics that it
has only one way to handle communications, and its application for
Pythonians is X.  A more progressive approach is even better.  What
frustrates me is muddle.  I perceive a real opportunity here to
make the best of the considerable intelligence working on common
issues (Tk, serial-port programming, file-system resource management,
Feather, new GUI toolkits, new protocol bindings, licensing, Stubs,
encryption legalities, autoconf travails, ...).
-- 

Cameron Laird           http://starbase.neosoft.com/~claird/home.html
claird at NeoSoft.com      +1 281 996 8546 FAX