Folks, would welcome any thoughts please on how to workaround the fact that sometimes the small handle that can be used to move note links around in map view is sometimes “behind” ie obscured by, a nearby note. When this happens (which is not every time), it seems to be necessary to manually move the note it is under, then use the handle to change the position of the link, then move the formerly obscuring note back into position. It would be preferable for all nearby notes to be in the “background” when a link is highlighted so that its position can be changed without interference by nearby notes (this might be a feature request please). Cheers, Jason Romney
Hi Paul, actually, no, the image does not show the situation to which I refer.
TB allows the path of the link to be manually altered through the use of a repositioning handle.
That handle does not appear in your graphic.
I just want the handle to be at the front of surrounding notes as it cannot be clicked when it is blocked by being underneath surrounding notes. Not sure why you believe we’d have a lot of lines and handles popping up and down. Only the handle associated with the highlighted note would suffice to allow repositioning to occur. Sorry if I’m not being clear enough.
Cheers,
Jason
I agree this would be nice.
It’s a fairly difficult thing to do. In the past, links and their widgets were drawn in the background of the view. This was bad in two ways. First, it placed links behind adornments, where they probably ought to be above adornments but behind other notes. Second, it meant the link layer was as large as the map. The link layer needs to be backed by a backing store, and for big maps that was more backing store than you could obtain.
So, fairly recently, links moved to their own transparent layer that is below notes but above adornments. This layer is the size of the window, not the map; instead of scrolling the layer, we respond to scroll actions by moving the links. Quite a lot of work went into optimizing this, because all those splines can be costly to evaluate in a big map with lots of links. But, the widgets still fall behind notes.
To put the link widgets where they rightly belong, we’d need a second link widget layer that is above everything else. That layer, too, needs adaptive scrolling. And it’s another layer that must be composited whenever a pixel changes in the window. The two link layers, moreover, will need to talk to each other quite a bit, because the link layer knows where the widgets go, and the widgets modify the links.
So, it’s rather a lot of work. As a workaround, you can move the note that’s sitting on top of the widget. That’s bad and it’s a bother, but it’s typically not that bad or bothersome. One can move lots of notes out of the way in the time it will take to implement that layer. And there are other things to do!
So it hasn’t been done yet. But it’s on the list.
Thanks Mark, your explanation makes perfect sense. I’ll soldier on as you suggest, moving notes if necessary, to move links. It is a relatively minor issue compared to all the value I get from Tinderbox everyday! Stay safe, JR