Relinking: draw the linkto an arbitrary point

I’m implementing relinking using the keyboard for accessibility, and trying to the the temporary drawn link to work as I want. It works fine if there’s a defined target using copyPortProperties(). It semi-works when there is no defined target port using setNoTargetPortPropoerties(). The problem with the latter is that the neutral point described in the documentation, seems to always be the current mouse position. How do I change this to be an arbitrary point of my choosing?

What key sequences are you trying to implement in order for the user to draw a new link? Or reconnect an existing link?

It sounds as if you want to continue using the LinkingTool and RelinkingTool, even though those tools aren’t designed to be used for purely keyboard InputEvents.

Right now I’m overriding the onKeyDown() methods for the most part. For this particular instance, We have nodes which have designated input and output ports, but there are some which don’t have an input or don’t have an output. I’m navigating around the nodes using the arrow keys, and by default ona new node, starting with a temporary link to the 1st port (approporiate for the end of the link). The current issue is for the case where the node has no ports of trhe appropriate type. I want a visual signal that the node is the current temporary target, but currently haven’t worked out how to do that. The current mouse coordinates aren’t appropriate when using the keyboard as it it usually in a completely irrelevant position.

A while ago we started development of an extension that permitted using keyboard keys to control a virtual mouse. This let users use any tool from the keyboard, including the standard linking tools. If this is what you want, I can share the code with you.

But that is not what you want, is it? It appears that you want to handle keys in a very specific manner for your app. Yet it also appears that you do want to use the standard linking tools, so that it can show a temporary link and temporary ports during the linking process, and so that it can do link validation, and probably other things too.

That is correct: there’s very little point in making the keyboard a mouse simulator, although you can. A keyboard isn’t limited by the need to move a pointer to a certain location, for example. It also allows you to overcome the fundamental problem witha mouse for those with visual impairment, which is knowing a) where the pointer is and b) where the target is on the screen. In many ways, efficient keyboard control will be app specific I think.

I am overriding doKeyDown to get at the keystrokes, but beyond that I am trying to use the built in behaviour as much as possible: the app does have to continue to function the way it always has when using a mouse. The subclassed tools are doing that key down processing and also adding aria-live text to the DOM for screen readers. So far I’ve managed to everything I’ve wanted to, although sometimes it is obvious that the API is evry mouse focused, and I think this particular problem is an illustration of that, where I don’t want the neutral relinking point to be the current mouse location.

I should add that the eventual aim is to meet the WCAG 2.1 guidelines.

Are you setting the Diagram.firstInput and lastInput at each keyboard event? You will need to set both their InputEvent.documentPoint and viewPoint each time.

Thanks, that gave me the solution.

Another quirk, I;ve noted for relinking is that the path drawn by the temporary link (before it os altered) is quite often different from the original link. In addition the alternative path drawn by the relinking tool drawn using the mouse is different from that when using the keyboard. Functionally it all works, but I’m surprised that the original temporary link path doesn’t match the original link’s path, especially when using the mouse (which hasn’t been interfered with by me).

Which version of GoJS are you using? In 2.2.20 we fixed a bug that sounds like it was related to what you are describing, which can only be seen in non-interactive situations (i.e. not with mouse/touch events).

2.2.17 at the moment.

And when you use latest?