Tk Source Code

The slider behaves strangely. You can not get hold of it, at least not in a precise way. I think the slider is correctly visualised, but the mouse pointer is not mapped correctly on the slider, but it is as if it was on the bar behind, depending on the position. I access Tk through Tcl::pTk, but here is a pure TclTK code to reproduce the issue. You need a lot of text in the text area to see the issue. This is even more true if the text area is small.

frame .textarea
text .txt -yscrollcommand {.s set}
scrollbar .s -command {.txt yview}
grid .txt   -in .textarea -row 1 -column 1
grid .s -in .textarea -row 1 -column 2 -sticky ns
pack .textarea

Please note that the problem is not there if using the macOS Tcl/Tk version (8.5.)

I fixed a few more glitches and merged the changes in core-8-6-branch and trunk.

Thank you, Marc. I can confirm that both the ttk as well as the standard scrollbars work like expected with the latest update. Great job!

@Takamoto: Thanks for testing!  I think you tested with f83ff783, which had
the minimal thumb shape being a circle. Check-in
 [https://core.tcl-lang.org/tk/info/a82cd76ed5b6eb60|a82cd76ed5]
increases the minimum size to match Apple's minimum size and also makes the
Tk scrollbar work correctly.

Great job! I've tested the bug-fix branch for tsk::scrollbar (which I changed to in my entire implication) and it works fine. The only shortcoming is that the thumb gets to a circle in its minimal size, which is fine, even if remains quite untypical. So I slightly changed the values and recompiled to have a more natural "small thumb" size. Changing it to:

    if (orientation == TTK_ORIENT_HORIZONTAL) {
	*minHeight = *minWidth = 8;
    } else {
	*minWidth = 16;
    }

seems to make the behaviour even more in line with other applications. Maybe you can consider to adopt it.

The bug-fix branch now contains a fix for the Tk scrollbar.  It draws the
scrollbar directly, rather than calling HIToolbox.  That way we can make
sure that the thumb is drawn at the correct size, which makes it behave
as expected.  This only applies to macOS 10.9 and later.  Earlier systems
still use HIToolbox.  The erratic behavior reported in this ticket still
occurs on 10.6 and 10.7.  Interestingly, on 10.8, which was the first release
to use the flat scrollbars that have been used ever since, the HIToolbox
draws the thumb at the correct size.

It would be very helpful if someone were to review the bugfix branch, so these
changes could be included in the 8.6.10 release.

A good demonstration of the issues with the tk scrollbar can be seen with the
"Colors" demo.  With the current core-8-6-branch tip, a mouse click near the end
of the scrollbar thumb does not "grab" it.  Instead it is interpreted as a click
in the trough outside of the thumb.  In other words, the thumb as drawn by
HIToolbox is quite a bit larger than Tk thinks it should be.

By the way, @Takamoto, it is the generic Tk code that chooses to make the size
of the thumb be linearly related to the percentage of the total content that
is visible in the window.  That choice is not made by any Mac-specific code.
Evidently HIToolbox does not use a linear relation.  But whatever they do use
is undocumented and reportedly also different from what is used by the scrollbar
in an NSScrollView. The mac-specific Tk code is attempting, and failing, to
guess what percentage should be reported to HIToolbox in order to trick it into
drawing the thumb as if Tk's linear relationship were in effect.  This is very
hard to do.

The fix for the ttk::scrollbar was merged into core-8-6-branch and trunk.
I am leaving the ticket open until a fix for the standard tk scrollbar
emerges, or its weaknesses get documented.

I fixed the problem with a too-small thumb for the ttk::scrollbar.  It was just
a simple bug.  All I needed to do was to set both a minimum height and a minimum
width in the size function used for the thumb element.

The patch is in check-in
[https://core.tcl-lang.org/tk/info/3a3a3b8d6a0b91ff|3a3a3b8d]
to the
[https://core.tcl-lang.org/tk/timeline?r=bug-8476b75781|bug-8476b75781]
branch.  Please test!

Note that this does not fix the standard scrollbar.  If anyone has a suggestion
for how to do that, please post it.

I'll defer to whatever advice Marc offers on the ttk::scrollbar question.

Sorry if my suggestion is naive: It seems to me that the slider size and the amount of advancement performed by moving it is a linear function (linear to the amount of lines in the text widget). Wouldn't a change of this function from linear to a x-factor improve the behaviour of the slider with longer texts without affecting shorter ones? 

Should I open a new ticket for the ttkscrollbar and the min. slider size? Or do you consider both scrollbar and ttkscrollbar as "won't fix"?

In fact, I would probably close this as a "won't fix" because the Tk scrollbar has been optimized pretty much as far as it can on the Mac. HITheme is an imperfect mechanism for rendering scrolling, but it works better with Tk than the NSScroller API. Other projects that use HITheme for scrolling, such as Apache OpenOffice, display similar performance issues from time to time.

The ttk:scrollbar did not exist on the Mac until Marc did a from-scratch implementation of it for a few different reasons: 1. The API for the themed widgets and how they are constructed differs from how the HITheme API rendered scrolling elements; 2. Unlike on Windows, there was only one theming API for scrollbars and the tk scrollbar already had that theme; it was simpler to map the ttk::scrollbar to the standard scrollbar because there was no difference in appearance. Marc's implementation of the ttk::scrollbar was based on his work having Tk pick up the Dark Mode changes on Mojave--doing a full-blown implementation of ttk::scrollbar was not in his original plans, I suspect. 

The ttk::scrollbar, which has a different and more efficient design internally than the Tk scrollbar thanks to Marc's work, seems to handle the long text display better in terms of scrolling, but the scroll button itself does not not render correctly in the linked example with hundreds of lines of text; it is so small that it is hard to see. And I would disagree that you should never use the Tk scrollbar. First of all, there are thousands of lines of legacy Tk code that use the standard scrollbar, and this works fine in the vast majority of use cases. It seems to get a bit sticky in the longer displays, as in this example, but Marc, Francois and myself have put in a lot of work on improving its performance and display in the last couple of years.

I agree that there definitely needs to be some documentation.

The story is a bit messy. The "issues" with the Tk scrollbar have existed
(undocumented) for a very long time. Moreover, until very recently there was
no ttk scrollbar for Aqua at all.  There was an (undocumented) hack in the
Tcl library which mapped the ttk scrollbar command to the Tk scrollbar. That caused other problems since the constructor commands do not have the same signature.

Even though the ttk scrollbar now exists in all versions of macOS, the issues with mapping mouse events to the approrpriate part of the scrollbar are only
resolved in the more recent systems whose scrollbar has the same appearance
as the current one. It doesn't seem practical to try to fix the older OS's.
But I'd like to look at whether there is a relatively simple way to fix the
Tk scrollbar on the newer systems.

<blockquote> …Tk scrollbar has never worked in Aqua and it never will work as long as HIToolbox is used to draw the scrollbar…</blockquote>
<blockquote> …I suggest tweaking the ttk::scrollbar code to handle the case of a tiny thumb and ignoring the issue with the tk scrollbar which should basically never be used on the Mac…</blockquote>

If users are not use the non-Ttk scrollbar on Aqua if they want to avoid issues, then I think they need to be made aware of that without having to find this discussion. Will some sort of advisory warning against the use of non-Ttk scrollbar on Aqua be posted, e.g. in the scrollbar documentation and READMEs?

Thank you very much for your valuable feedback. I switched to ttkScrollbar immediately as I can see there is no point in maintaining the non ttk variant. It would be great, however, if the minimal size of the tiny thumb would be addressed.

To understand what is going on here you need to start by reading the long
discussion about the Tk scrollbar in ticket
[https://core.tcl-lang.org/tk/tktview?name=0d63621b6c|0d63621b6c].
The executive summary is that the Tk scrollbar has never worked in Aqua and
it never will work as long as HIToolbox is used to draw the scrollbar.  Moreover,
it is necessary to use HIToolbox to provide scrollbars that look correct in
older versions of the OS.  The basic problem is that no one has figured out
how to convert between Tk's notion of where the thumb is located and HIToolbox's
notion of where the thumb is located.

On the other hand, the ttk::scrollbar does work (almost) correctly on recent
versions of macOS.

I say "almost" because this ticket actually does reveal a problem with the
ttk::scrollbar.  Namely, the drawing code does not correctly handle the case where the natural size of the thumb is extremely small, such as when you have
a 3-line text widget containing hundreds of lines of text.
 
I guess that the smallest possible thumb should be drawn as a circle.
Currently it appears as a tiny blob of some sort.   If the scrollbar is so
small that the circular thumb essentially fills it up then dragging the thumb
will not work in any reasonable way, since moving the thumb by a couple of
pixels would have to scroll from the first to the last of hundreds of lines
of text.  However, clicking above or below the thumb should move the text by
one page.  Of course this requires that there be enough room above and below
the thumb to allow clicking in that space.

I suggest tweaking the ttk::scrollbar code to handle the case of a tiny
thumb and ignoring the issue with the tk scrollbar which should basically never be used on the Mac.  With quite a bit more work, the standard tk scrollbar
could be rewritten to use the same drawing code as is used in the ttk scrollbar
on recent versions of macOS. I think the amount of work needed to do the
analogous thing for, say, macOS 10.6 would far exceed the value of doing so.

A slightly adapted script to see the scrollbar. Please, to see the issue copy and paste >200 lines of text, for example from https://gist.github.com/phillipj/4944029

frame .textarea 
text .txt -yscrollcommand {.s set}  -height 3
scrollbar .s -command {.txt yview}
grid .txt   -in .textarea -row 1 -column 1
grid .s -in .textarea -row 1 -column 2 -sticky ns
pack .textarea
.txt insert end {a
b
c
d}

Probably a bit out of topic, but it may help to spot the problem: with this example in Tcl::pTk (I am sorry I could not call scrolltext directly in Tcl/Tk)

use Tcl::pTk;
my $mw = MainWindow->new();
$mw->Scrolled('Text')->pack();
MainLoop;

shows quite well what it is happening. If the quantity of text is big and you reduce the size of the text area, the visual size of the slider gets reduced till it almost disappears. Note I am a layperson with Tcl/Tk but, I guess this is the same problem (only that the in the TclTk code above the slider is plotted).

> This example does not plot a scrollbar

For me it does (on Windows).

Perhaps you need to enter some text in the text widget to make it appear? The OP said (but didn't provide a script filling the text widget):

> You need a lot of text in the text area to see the issue.
> This is even more true if the text area is small.

This example does not plot a scrollbar, at least in my testing with the tip of core-8-6-branch on Mac/Mojave. 

The behavior you describe was something of an issue between 8.6.8 and 8.6.9, but a lot of work has been done recently on the scrolling--I'm not sure if that has made it into a versioned release of Tk yet. If you can put together a cleaner example, I will test it.

Cc'ing myself. I have not yet tried reproducing the issue.