Responsiveness of the nodes in the thread arc

Does it persist if you make the thread arcs view wider?

Yep, exactly the same.

What is your OS? Is it a Retina screen […]? Any pattern you find to the behavior would be useful.

10.10.3. But it was the same already before. I’ve noticed it from the the first time on after having discovered the arcs (that is, about Dec 2014.). It’s a Mac Mini, no Retina. Later I’ll install it on another Mac to see if it’s there too. I’ll let you know.

No recognizable pattern, as far as I can tell. It has always been like this. And the number of mouse pointer hovering actions it takes varies from 0 to about four or five. No pattern either.

It feels like attempting to drive your car in reverse into a very narrow garage. Sometimes you’re in at the first, sometimes it takes 5 attempts ;-)

I'd probably need to make some kind of debug version to know more, but it would be much better if I could reproduce it myself.

I already feared that you can’t reproduce it. Otherwise it would have been high on your fixes list, I’m sure, because it’s quite aggravating and makes you emit ugly words ;-)

when moving the mouse vertically through the dots.

Heck, you’re right! If I make a horizontal “U-turn” (literally), when moving from one dot to the next, it works reliably. Strange that I didn’t discover it. Probably because I’m not used to move my mouse in predefined curves ;-) (you should mention this technique in the manual ;-)

I'll note to look into it, but I've got a lot on my list these days.

Thank you.

best,

Tom

I think I’ve found the pattern. There is just a minimum mouse travel distance required to make the dots responsive.

That means, if we’re moving vertically there must be at least a free distance of 8px between two dots. See screenshot.

So, making the thread arc wider – or, more effective: longer – indeed helps, but only if there aren’t too many posts in the thread, so that the resulting dot distance can grow bigger than 7px. (Which apparently wasn’t the case when I tried it before.)

Well, once knowing this, I can adjust the width/height accordingly, so it isn’t really an important issue anymore.

Thanks for the inspiration!

PS:

I think a quick and effective fix would be to set minimum column width of the thread arc field to 31px. This seems to produce exactly the required minimum vertical dot distance of 8px (if the tread isn’t to large).

Currently the min width of the column is 29px.

Ok, I've increased to 32px and it really does seem to help, but it
doesn't solve the problem when there is a lot of dots. I guess it would
be nice if the dots decreased in size when necessary. And even better,
zoomed into the area of the currently “active” dot similar to the OS
X dock. Some day.

Thank you.

For large threads (many dots) I have another proposal for a quick workaround:

Just make Thread Arcs available in the Widescreen layout (⌘5). The Widescreen layout is predestinated to be used with Thread Arcs: there’s the complete window height available, for displaying also the longest threads.

Of course this would require some minor UI restructering (menu and shortcuts).

And, to go slightly further:

It would also be nice if the thread arcs would not be mutually exclusive with the correspondence layout. I always wondered why I can’t display both.

So, if there’s not too much work behind it, I think a good idea would be to take Thread Arcs out of the Layout menu and make it a global option in the View menu (combinable with the currently active layout).

I should at least redesign the default layouts, but the perfect solution would unfortunately require a lot of work (placing and binding the various parts of a layout in arbitrary ways using a GUI).

Note that the underlying system is very flexible. Low level you can create new layouts. For example, see here.

Note that the underlying system is very flexible. Low level you can create new layouts. For example, see here.

Thanks for the hint; I didn’t know that.
parzonka’s plist works fine so far. Very nice!