Currently overloading.py raises an error if it finds a type annotation that uses the typing.Union type. This seems to be because it is a class. (see line 76 of overloading.py)

It would be good to add support for these "custom" types before fully type hinting the project.

It might be as easy as replacing the isclass code with something like this from generic.py.

As described in title.

Issue exits in edge.py, on line 122.

    def width(self):
        """Returns the thickness of the edge."""
        return self._weight

Proposed solution

Replace self._weight with self._thickness

Also maybe make the naming more consistent? Width is called both thickness and width. And in the edge.set_width() function, the parameter is called weight which makes things confusing and might've led to this issue.

Later today when I've got time i'll submit a pull request.

The html code is kinda gross, would be nice to refactor it to be less massive.

I suspect there's a lot of styles that are unused and some the js can be cleaned up

Probably should let the user know if there is a new feature or patch version. So that they can download the new version and get whatever fix.

Proposed solution

Check on the localhost ui, and put a banner up if there is a new version. Probably reuse some of the code from the gh-pages branch, and how the docs have the version switcher.

In terms of sending the installed version of PyNode Next to the client, just dispatch an event when the user connects to the socket. (through self.canvas.onmessage or something like that)

version_dispatch_dict = {'isPyNodeNext': True, 'type': 'version', 'message': 'v1.9.1'}
self.canvas.onmessage('getPyNodeNextVersion', lambda: self.canvas.dispatch(version_dispatch_dict))

let socket = initSocket(function() { 
  canvas.message('getPyNodeNextVersion') 
}, dispatch);

And then just grab the message in the js dispatch function and handle it.

When the node's value becomes larger than the circle can contain, it becomes hard to read the text, as it is a very similar colour to the background colour.

The original PyNode solved this by having outlines on the text. Algorithm X doesn't seem to support this kind of thing, so it might need to be implemented with external d3 stuff in ui.html.

Alternatively, the nodes could dynamically size to fit the text in (like they do in GraphX). Although, this would most likely remove the nice circle shape and would mean that the size property would be basically useless as the nodes would not have one consistent size.

From the original PyNode:

• node.set_position(x, y, relative=False) - Sets the static position of the node. x and y are pixel coordinates, with (0, 0) being the top-left corner of the output window (the standard size of the window is 500x400). If relative is set, x and y should instead be values between 0.0 and 1.0, specifying the node's position as a percentage of the window size.
• node.position() - Returns a tuple with the (x, y) coordinates of the node. Should be used in asynchronous function calls.

This was fine back then, but because we don't know what the size of the user's screen we probably are going to have to make them all relative.

Also, AlgorithmX's coordinate system means that (0, 0) is in the middle of the screen.

Fixes the problem where you'd have to double set the edge's weight to None if you wanted it to be None.

before:

graph.add_edge('a', 'b', weight=None, directed=False)
# doesn't show the weight 'None'
edge.set_weight(None)
# now it does

after:

graph.add_edge('a', 'b', weight=None, directed=False)
# shows the weight 'None'

Closes #13 and EHN-17

Removes legacy arguments from PyNode Next. (Thankfully none of them used the overloading system so the errors should be at least useful)

Closes #26 EHN-27

The positions of the relative scale are incorrect due to the zoom done to make the nodes bigger. The zoom appears to change how AlgorithmX handles its relative positions. Not sure how to fix this one. In the worst case we can just disable the zoom.

the node's position is not defined in the data method and doesn't move to the correct position when added after it is initialised.

a = Node('a')
a.set_position(1,1)
graph.add_node(a)

doesn't work, but the following does:

a = graph.add_node('a')
a.set_position(1,1)

Some methods still have legacy arguments in their original locations so that it can maintain compatibility with the original PyNode. Most of the methods that have this are the style ones.

Proposed solution

Remove the outline kwarg from set style methods. It's in the middle of the arguments and results in issues where there is an option that does nothing before an option that actually does something. Leads to a situation where the user could expect something like node.set_value_style(13, Color.WHITE) to do one thing, but it actually does something else.

branch: remove-legacy-arguments-ehn-27

Currently there is a mix of single and double underscores used for private methods. To actually get the proper python private methods these should all be double underscore.

A lot of the function arguments are id and redefine that builtin (hence their different colouring in highlighters). Codefactor gets really annoyed about this, although the use of id doesn't seem to have caused any problems so far.

Consider replacing this id with something like uid or something similar. I'm not entirely sure what a good substitute would be.

Currently PyNode Next uses the default canvas server, this has some issues in how it understands where files are and what to load. This results in the slightly odd looking code in core:

base_path = os.path.relpath(__file__)
self.custom_ui = f"{Path(base_path).parent}/ui.html"

This is due to how if you use a custom html file (like PyNode Next does) it switches to using a relative file handler, rather than an absolute one. Hence the relpath call.

This problem results in the unfortunate side effect that we cannot package PyNode Next for PyPi, as it is unable to find a suitable relative path to work with. Meaning that users have to download a new copy of PyNode Next for every project (or move the same copy between projects). This also means that when uploading work done with PyNode Next, it will also include the PyNode Next source files. (this is both good and bad. good because it means that whatever version of PyNode Next is used in a project will be the same with the same project on a different machine, but bad for the reasons outlined before).

If we were to use a custom implementation of AlgorithmX's CanvasServer class, we would have more control over what path could be loaded. In theory we should just be able to replace the init function of CanvasServer.