Vasilis Vlachoudis <vasilis.vlachou...@cern.ch> wrote:
> I works within the same process.
> When I try to launch it twice, so I can have clipboard exchange between
> different processes
> I get the following exception:
> Traceback (most recent call last):
> File "/usr/lib/python3.6/tkinter/__init__.py", line 1702, in __call__
> return self.func(*args)
> File "foo.py", line 41, in paste
> res = root.tk.call(clip)
> _tkinter.TclError: invalid command name "139879786444744cp"
oh sure, I did not think about *that* :)
This is not going to work of course with two separate program instances.
> I did something else.
> I've used the binascii.b2a_hex() and a2b_hex() functions
> to convert the bytes() to a hex string and the reverse (double in size,
> and a useless UTF-8 conversion, encode/decode)
> This way it works but not a clean approach,
> since I am copying in the clipboard binary data in a form of ascii.
Actually I believe, if you got it working, that it is probably the most
"clean" approach, at least as long as you stay within Tk; I guess that
other software might only receive "junk data" from the clipboard, though.
> Is there a way to create a new mime format and advertise
> the format somehow in the clipboard?
Quoting "man clipboard" again:
" Type specifies the form in which the selection is to be returned (the
desired ``target'' for conversion, in ICCCM terminology), and should be
an atom name such as STRING or FILE_NAME; see the Inter-Client
Communication Conventions Manual for complete details. Type defaults to
The format argument specifies the representation that should be used to
transmit the selection to the requester (the second column of Table 2 of
the ICCCM), and defaults to STRING.(...)
The format argument is needed only for compatibility with clipboard
requesters that do not use Tk. If the Tk toolkit is being used to
retrieve the CLIPBOARD selection then the value is converted back to a
string at the requesting end, so format is irrelevant."
So I guess that the answer is probably "yes" here, but it sounds to me
like a non-trivial task that might require a considerable amount of
> I've been reading and debugging a bit what firefox is doing and how the
> selection is treated. I couldn't find anywhere how to handle binary
> data, but firefox when you copy an image it creates customs mime types
> like image/png that contain the data in a form '0x39 0xf7 0xb8 0x8f
> 0xff ...'
Probably they are doing something of that ICCCM compliant things, but I
really don't know anything about that.
> Now I don't know if it is tk/tcl or _tkinter that makes this
> interpretation or the data are really ascii written in hex format, but
> I think even like this it can work for me.
I think it is surely tcl/tk that does it, tkinter only calls tk's
clipboard commands. However tkinter in some situations *might* do some
"mangling" to the data that tk returns (e.g. in the example from my
previous post, when the "embedded" helper func would return a list,
self.tk.call() would turn this into a tuple).
.-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-.
Fascinating, a totally parochial attitude.
-- Spock, "Metamorphosis", stardate 3219.8
Tkinter-discuss mailing list