| msg29069 - (view) |
Author: Ronald Oussoren (ronaldoussoren) *  |
Date: 2006-07-06 08:34 |
| I've done some work on fixing the menus for IDLE before 2.5b1, but recently found more toplevel windows that don't have their own menu. Both the Path Browser and Class Browser don't have a menubar of their own. The Tk implementation on MacOSX won't accept an empty menubar, but will replace that by a generic Tk menubar. |
|
|
| msg29070 - (view) |
Author: Kurt B. Kaiser (kbk) * |
Date: 2006-07-15 19:51 |
| Logged In: YES user_id=149084 I suppose this is also true for the debugger? I'd consider this a bug in OSX Tk, it should be reported there. Without a specific need for a menubar, all it does is take up valuable vertical space. And continuing to add OSX special casing clutters up the IDLE code; IMO it should be limited to situations where functionality is compromised. |
|
|
| msg29071 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2006-07-18 12:20 |
| Logged In: YES user_id=580910 These menu problems are at the very root caused by differences in the way menus work on OSX (one application wide menu at the top of the screen) and most other systems (optional menus for every window). Applications on OSX must have some kind of menu (or be full-screen, but we don't want that for IDLE), Tk uses the per-window menu for the currently selected window for that. If a window doesn't have a menu it makes up one and I haven't found a way yet to override that menu (which would solve that problem once and for all). I do believe that my other changes really are good, they make IDLE perform more like a true OSX application. This is important because IDLE is the default IDE, and hence probably the first thing naive OSX users will see of python. BTW. AquaTk really sucks, which makes it annoyingly hard to create a really good OSX citizen of IDLE and I have given up on getting there. If I understand the lazyweb correctly you're supposed to port your appliations to some other GUI library (Tile?) to get a native L&F for lots of widgets and standard dialogs. |
|
|
| msg29072 - (view) |
Author: Kurt B. Kaiser (kbk) * |
Date: 2006-07-22 21:23 |
| Logged In: YES user_id=149084 > Tk uses the per-window menu for the currently > selected window I assume you mean AquaTk uses the per-window... Please put in a bug request on AquaTk to get it to conform to how Tk handles this menu on Linux and Windows. Then downgrade the priority of this bug or close it. Does the debugger have the same problem? |
|
|
| msg29073 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2006-07-23 07:26 |
| Logged In: YES user_id=580910 Yes I mean AquaTk. The debugger has the same problem (as expected because it doesn't define its own menu) The behaviour of AquaTk is a feature, not a bug. Appearently the default menu is inheritted from the root ("."). I'll see if I can override that menu in macosxSupport.setupApp. |
|
|
| msg29074 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2006-07-23 09:35 |
| Logged In: YES user_id=580910 Changing the default root menu is indeed possible without changes outside macosxSupport.py. I'm going to apply the attached patch later today. Annoyingly enough AquaTk still adds an (empty) Help menu to our menubar. It would be nice to fill that menu, but that would IMHO add to much code. I'm happy enough to blame that glitch on AquaTk. |
|
|
| msg29075 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2006-07-23 09:46 |
| Logged In: YES user_id=580910 Applied in revision 50785 |
|
|