Re: [MACTCL] Menubutton and Checkbutton width wrong on MacOS X

[Russell E. O. <ro...@uw...>]

In article <50B...@co...>,
 Kevin Walzer <kw...@co...> wrote:

> On 11/28/12 4:20 PM, Adrian Robert wrote:
> > I think if it's possible for Tk to support a widget option consistently 
> > across platforms it should do its best to do so.  What is or isn't best 
> > programming practice is one thing, but the API is kind of like a contract, 
> > that allows cross-platform applications to be written without the need for 
> > a lot of if-then's to handle different environments.
> 
> I certainly agree with this in principle. And, indeed, the internal 
> implementation of calculating menubutton width is very similar on both 
> Unix and Aqua (didn't check Windows):
> 
> Unix:
> 
> 	avgWidth = Tk_TextWidth(mbPtr->tkfont, "0", 1);
>      .....
> 	width = mbPtr->width * avgWidth;
> 
> Aqua/Cocoa:
> 
> 	    int avgWidth = Tk_TextWidth(mbPtr->tkfont, "0", 1);
> 	    width = mbPtr->width * avgWidth;
> 
> According to Russell, these similar implementations produce very 
> different outcomes on the different platforms. The reason for this, I 
> believe, is the difference between font rendering engines on the two 
> platforms. His suggested fix, under Aqua, is to increment the width by 
> some specified amount, which, I'm inferring, would make the Aqua 
> implementation look more like the X11/Unix implementation visually. 
> (Haven't tested it.)

Is is possible that the width (in pixels) on unix applies to the text 
region of the widget, whereas on MacOS X the width in pixels applies to 
the whole widget (including the checkbox for a checkbutton, the menu 
indicator for a menubutton, etc.)?

If the width was in pixels, I would agree that widgets look different on 
different platforms, live with it.

But in this case width is in characters, and (until Tk 8.5) it meant 
that the widget could display approximately that many characters. That 
is a very sensible, simple and self-consistent meaning.

My suggested workaround is rather crude. I'd rather see it done more 
accurately. But I feel very strongly that this should be fixed in Tk, 
not inside the code every user of Tk uses.

Adrian: you mentioned that you have a more sophisticated workaround. 
Would you be willing to post it?

Since the option for specified width is supported, why not support it 
properly and in a way that is easy to use cross-platform? Fixing it in 
one place allows:
- Doing it right once
- Simpler code for people using Tk to write cross-platform scripts

You say that we shouldn't use width, but it used to work just fine and 
it would be pretty easy to make it work fine again.

I'm disappointed to see this change in direction for Tk. I maintain a 
python application that has to be functional (not necessarily beautiful) 
on unix, MacOS X and possibly Windows. Tk 8.4 worked well for that 
purpose. One code base did everything with only a bit of 
platform-specific code. The conversion to Tk 8.5 has been much more 
complicated than I ever dreamed. If I had not long ago wrapped most Tk 
widgets in wrapper classes I would have been in terrible trouble.

I thought incorporating ttk was a great idea for Tcl/Tk: those who 
wanted native looking widgets could use ttk and live with having only a 
few configurable parameters (a safe minimum set that worked on all 
platforms). But I never realized that the old cross-platform widgets 
were going to become so platform-specific as well.

Another issue like this that Kevin mentioned is menubutton colors. For 
some reason on MacOS X the bg config parameter sets the foreground, but 
only if fg has never been set. Huh? How can that possibly be reasonable? 
It sounds like something out of Catch-22. Would you really want to 
document such bizarre behavior? if bg cannot set the background color 
then for heavens sake ignore it, don't have it *maybe* set the 
foreground color!!! But it's a feature, not a bug, so it won't be fixed.

-- Russell