[Pythonmac-SIG] tkinter and tcl console window

Ronald Oussoren ronaldoussoren at mac.com
Fri May 19 19:01:59 CEST 2006


On 19-mei-2006, at 18:26, Kevin Walzer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ronald Oussoren wrote:
>
>>
>> I'm going to replace my hack with this suggestion.
>
> Glad that worked.
>
>>
>> Now that I have the attention of someone that actually knows  
>> something
>> about tk :-)... This[1] document mentions I can implement support for
>> open events by implementing the tk  
>> function ::tk::mac::OpenDocument. Do
>> you know how I can implement such a function in python?
>
> I don't know the exact Python code, but the way I do this in Tcl is to
> define a procedure that opens a file and then link this procedure  
> to the
>  ::tk::mac::OpenDocument procedure; the ::tk::mac::OpenDocument call
> passes a list of files dropped on the Wish app icon to the actual code
> that opens and loads your documents. It looks something like this:
>
> proc openFile {file} {
> 	#do stuff here
> }
>
> proc ::tk::mac::OpenDocument {file} {
> 	openFile $file
> }
> Perhaps you could use something like this to wrap the raw Tk command:
>
>
> def macOpenDocument:
> 	app.top.tk.call('::tk::mac::OpenDocument')
>
> You'd still have to do the other part of the equation, that is,  
> linking
> the macOpenDocument function to the other IDLE code that actually  
> loads
> files for editing.
>
> Sorry if my Python isn't quite right here, but hopefully you get  
> the idea.

Getting the python right is easy, learning Tk through the mostly  
undocumented tkinter library is worrying me :-)

You're suggestion doesn't help here though, I somehow need to define  
a new TCL proc from python.

With some code browsing I've found how do do this:

<quote>
def doOpenFile(*args):
	print *args

someTkObject.createcommand("::tk::mac::OpenDocument", doOpenFile)
</quote>

I could have known that it would be something simple :-)

>
>>
>> And a last question for now: is the look&feel of the latest tcltkaqua
>> universal release[2] more OSX-HIG compliant than the version shipped
>> with OSX? The L&F of IDLE really sucks right now, I have fixed the  
>> easy
>> things (menus, statusbar) in my local tree, but know to little of
>> tkinter/tcltkaqua to fix the rest (dialogs without title bars,  
>> foreign
>> looking tabbed view in the preferences window, window background  
>> isn't
>> striped, ...) in a reasonable time.
>>
>
> There are some improvements. Text entry fields have a proper blue  
> "focus
> ring" on them, and there are other little things. The other parts are
> do-able, but would either require either rewriting a lot of IDLE's  
> code
> (to correctly map dialog boxes to HIG-conformant ones), or using a
> binary extension called "Tile"  (included with my installer). Tile
> solves a lot of basic Tk's deficiencies with the HIG, including the
> striped background, notebook tabs, etc. I don't think Tile has really
> made it to Tkinter yet in terms of use; there's an alpha-level wrapper
> of it, but the site is chronically off-line and, to my knowledge, no
> applications really make use of it yet.

> You mentioned earlier about making IDLE more HIG-conformant. Is  
> this the
> kind of stuff you had in mind? I might be able to contribute  
> something a
> bit later, after a couple of other projects I'm working on are  
> complete.
> But some of these changes would be so extensive (adding Tile, for
> instance, which would also improve the L&F on Windows) that I  
> anticipate
> getting them rolled back into the main Python tree would be hard: it
> would require Python to ship Tile as well as Tcl/Tk, for instance. So
> I'm not sure how much you'd want here.

This is indeed the kind of changes I had in mind. But those changes  
sound like a lot more work that I'm willing to do. If I am going to  
spend significant time on fixing IDLE I might as well write my own  
IDE :-)

There would also need to be discussion on idle-dev and/or python-dev  
on the Tile-related changes (and other large changes), I wouldn't  
know if those would fly. My guess is that nobody will object if this  
results in a better L&F on Windows and Linux as well.

Ronald


More information about the Pythonmac-SIG mailing list