Menu
▾
▴
tcl-mac
|
From: Russell E. O. <ro...@uw...> - 2012-11-26 21:32:07
|
I've reported these as bugs and been told they are best discussed before being changed, so here goes: On MacOS X if one specifies a nonzero width (in chars) for a checkbutton or menubutton, the number of chars that will be displayed is far less than the width. This is a change from Tcl/Tk 8.4 to 8.5 and I'm very confused as to why this occurred and why not fix it? In Tcl/Tk 8.4 when a widget took a width parameter measured in chars you could count on the width showing roughly that many chars. Now in 8.5 you cannot. (I have not tried 8.6, but I'll be surprised if it's different than 8.5). This ruined the appearance of much of my application until I hacked around it. Fortunately I subclass checkbutton and menubutton so I could apply the hack in just one place. But I hate to leave things like that in my code. Would it be OK to change Tcl/Tk so that the width option on these widgets actually does specify roughly how many chars could be displayed? Its a simple change, though admittedly one that requires a Mac-specific branch. I guess an obvious question is how widely others are already hacking around this issue. (I assume most users use width=0 and thus don't see this bug). My use case: often I have widgets that can display one of several strings. In that case I usually prefer to specify a width sufficient that the longest string can be displayed. That way the containing window retains its size. -- Russell P.S. the bug numbers are: 3580194 for menubutton not yet reported for checkbutton, given the cold reception to the menubutton bug |
|
From: Kevin W. <kw...@co...> - 2012-11-28 16:07:28
|
Hi list, On 11/26/12 4:31 PM, Russell E. Owen wrote: > > Would it be OK to change Tcl/Tk so that the width option on these > widgets actually does specify roughly how many chars could be displayed? > Its a simple change, though admittedly one that requires a Mac-specific > branch. I guess an obvious question is how widely others are already > hacking around this issue. (I assume most users use width=0 and thus > don't see this bug). I would appreciate others weighing in on this. As I've commented to Russell at the bug report, my view is that what he's seeing is not a bug but simply the platform-specific implementation, i.e. Cocoa may simply calculate text width and render it a bit differently than did Carbon. (Carbon used QuickDraw and then ATSUI for its text rendering, while Cocoa uses CoreText.) If he does not use hard-coded widths then the text displays fine, although it may change the layout of his app. My understanding is that it's not considered a best practice in Tk to hard-code text widths and font sizes, because font rendering can vary so widely across platforms: what looks good on one platform may look quite different (and not so good) on another. My limited experience with deploying a Tk app on Windows confirms this. I'm reluctant to go against the platform-specific grain and investigate a change that would preserve cross-platform compatibility at the expense of best practices on the specific platform, cf. how other Cocoa-based apps do it. I'm especially reluctant to do so (and not even sure it can be done) given that Russell has found a workaround for his use case. Other opinions are welcome. Thanks, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Adrian R. <adr...@gm...> - 2012-11-28 21:20:38
|
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. This is why when ttk was added, the approach was to provide a more minimal set of configuration options for each widget, to ensure that it could be adhered to for each platform, rather than providing a bigger set of which parts might or might not work in a given environment. -Adrian On 2012/11/28, at 11:07, Kevin Walzer <kw...@co...> wrote: > Hi list, > > On 11/26/12 4:31 PM, Russell E. Owen wrote: >> >> Would it be OK to change Tcl/Tk so that the width option on these >> widgets actually does specify roughly how many chars could be displayed? >> Its a simple change, though admittedly one that requires a Mac-specific >> branch. I guess an obvious question is how widely others are already >> hacking around this issue. (I assume most users use width=0 and thus >> don't see this bug). > > I would appreciate others weighing in on this. > > As I've commented to Russell at the bug report, my view is that what > he's seeing is not a bug but simply the platform-specific > implementation, i.e. Cocoa may simply calculate text width and render it > a bit differently than did Carbon. (Carbon used QuickDraw and then ATSUI > for its text rendering, while Cocoa uses CoreText.) If he does not use > hard-coded widths then the text displays fine, although it may change > the layout of his app. > > My understanding is that it's not considered a best practice in Tk to > hard-code text widths and font sizes, because font rendering can vary so > widely across platforms: what looks good on one platform may look quite > different (and not so good) on another. My limited experience with > deploying a Tk app on Windows confirms this. > > I'm reluctant to go against the platform-specific grain and investigate > a change that would preserve cross-platform compatibility at the expense > of best practices on the specific platform, cf. how other Cocoa-based > apps do it. I'm especially reluctant to do so (and not even sure it can > be done) given that Russell has found a workaround for his use case. > > Other opinions are welcome. > > Thanks, > Kevin > > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > INSIGHTS What's next for parallel hardware, programming and related areas? > Interviews and blogs by thought leaders keep you ahead of the curve. > http://goparallel.sourceforge.net > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
From: Kevin W. <kw...@co...> - 2012-11-28 22:27:26
|
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.)
I may be wrong here, but this strikes me as the wrong approach. Is the
goal to have Tk fit in reasonably well on the Mac, and to take advantage
of native API's to do so, or is to preserve cross-platform compatibility
and visual consistency regardless of the contortions to the C API on a
specific platform? Historically the practice has been the former: the Tk
API is mapped to the underlying native API as much as possible, but
without forcing it to conform when it's illogical (or impossible) to do so.
Hence Tk buttons on the Mac ignore a number of flags, such as -bg,
because the native button cannot be configured this way. In another
example, both a -bg and a -fg flag on a menu entry only configure the
foreground because the background cannot be configured under Aqua menus;
the rationale was, I presume, to configure what could be configured.
(This is from another bug report Russell filed, 3588636, which I have
declined to implement because it would break code in the Tk demo on the
Mac.)
If a workaround to these issues can be implemented at the script level,
I think that makes a lot more sense. Implementing these kinds of changes
at the C level not only ignores a lot of past history in terms of Tk's
practices, but it also risks pushing the C API more in the direction of
spaghetti code. To be honest, there are few enough of us who understand
Tk's C API's standard implementation (my understanding of it still has a
lot of room for improvement); it's a bad idea to put in a lot of
exceptions and workarounds to that API.
Aside/rant: I still can't believe that the new edition of the Osterhaut
book blithely omits documentation of Tk's C API because so few people
work on it. What a foolish, shortsighted decision. There's no way to
attract developers to the toolkit if its C API is impossible to learn
from available resources. Thank God for Brent Welch's book.
Back to the question at hand. I believe Russell's problem can be solved
at the script level, and therefore, that's where it's best solved.
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
|
|
From: Kevin W. <kw...@co...> - 2012-11-29 01:58:42
|
On 11/28/12 7:29 PM, Adrian Robert wrote: > Has the possibility been eliminated that there is a bug in the Tk/Cocoa-specific portion of the underlying Tk_TextWidth() implementation that causes a wrong result? I fixed one bug in TkpMeasureCharsInContext() a while back and there could well be other issues elsewhere. Hadn't thought of that. What bug number was the MeasureCharsinContext? I'd like to take a look. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Russell E. O. <ro...@uw...> - 2012-11-29 19:54:29
|
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 |
|
From: Revar D. <rev...@gm...> - 2012-11-29 20:52:47
|
On Nov 29, 2012, at 11:54 AM, "Russell E. Owen" <ro...@uw...> wrote: > In article <50B...@co...>, > Kevin Walzer <kw...@co...> wrote: > >> 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.)? > As I (vaguely) recall from my attempts several years ago, to make Tk Carbon (NOT Coacoa) look more native, one problem is that buttons have big rounded endcaps that clip the viewable label text. Yet the measurement of width didn't refer to the label area, it referred to the entire width of the button. So if you specified a button with 2 chars width, it wouldn't actually show it's label, as the endcaps would be taking up all the space. My solution at the time, as I recall, was to add the endcap widths to the calculated button width. That way if you set a button with width 4, it would display about 4 characters in it's label area. |
