connorjak / connectatron Goto Github PK

USB 3.10 Host Controller gets saved as USB 3

Right now there are some screenshots but it's all just remaining from the node-editor repo.

Need to check for whether the pin supports multi-connect, then conditionally remove any previous links.

Users will require documentation for how to use Connectatron, especially as it continues to accrue more features.

Options:

• In-app UI popup from a question mark button or help menu option
  • Could be markdown formatted with proper imgui addons
• PDF distributed with the app
  • Harder to version-control

• Saves storage space
  • Depends how we implement
• Allows for updating devices across all projects
  • If a change is made on one project, the other projects don't continue to have outdated devices
  • Might be possible to do optional-updating per-device, with the option to create a new device using the old device data that's saved in the project
    • This ensures there is an opportunity to save data in case of accidentally overlapping names of devices, and other cases
• Enables #18

Illegal characters in name are not removed.

We have over 150 connectors and over 150 protocols; it's quite difficult to find what you need.

A way to, within a GUI, create and edit devices.

• Modify device name
• Modify device description
• Add and remove connectors
• Modify connector type (PinType)
• Modify protocols supported on connectors
• Modify connector description
• Save device to file

Got a few options for this:

• Warn on mismatched data
• Projects save filepaths to devices instead of unwrapping devices to straight json
  • Could result in edits to one project changing nodes in another, unless we work on some immutability features

A way to save a list of devices with quantities for the purpose of knowing which devices you have remaining after using some of them in a project. There is a somewhat similar feature in PCPartPicker.

Could also modify these devices with information such as broken connectors or other custom info.

Ability to open any device as a .con project file, which would allow for device internals planning, or just categorization of a big set of devices in a larger scope project. This would be recursive, and would have all of the connectors of the exterior device reflected on the inside.

Check connections for matching protocols.

As an extension of #1, store on a device whether a protocol on a connector is a Source, a Sink, or a Relay. This will allow proper walking of the path from sources of protocols to sinks, which will determine which protocols are actually supported the entire way through, and where a device drops a protocol.

There are likely imgui extensions that encapsulate this well.

One notable thing we can't yet do is give a warning that closing the editor window will discard unsaved changes. We could do that if we made our own exit button instead of using the OS one.

When dragging from a certain connector, it is possible to determine which devices have at least one compatible connector. We can filter the Add Device menu to those to speed up finding the device you need.

Also should check if it handles extra-connector-type-compatibility.

At the moment, Connectatron uses C++ enums and the magic_enum library for automated operations like stringizing all enum names.

This has the following limitations:

• Must follow C++ variable name character restrictions
  • Partially solved by underscore-encoding
• No way to add more connectors and protocols
• Difficult to add associative information like Category in a very flexible way
  • Currently implemented categories as ranges of the enumerations, so any connector or protocol cannot exist in multiple categories

Benefits that should be preserved:

• Connectors and protocols are only stored by string name
  • Changes to enum-order and metadata like category, etc do not disrupt the validity of the saved string
• Exactly one place to edit information about a single connector/protocol, no matter how many aliases that has
• Software only allows you to apply/change valid connectors/protocols

Could be as simple as "all proprietary connectors can connect to all other proprietary connectors", or something like having to match a key (like a specification title or part number).

Particularly for common connectors, readability of the interface would be improved if a recognizeable diagram of the connector or logo of the standard were shown instead of a generic connector symbol like we have now.

Having problems with vcpkg libraries...

Fixing this will allow for the CI to produce automated releases.

At the moment I use std::random stuff to get a uniform 1->100,000 random. This needs to be redone to get a better guarantee of uniqueness.

At the moment it is possible for multiple links to use a single pin.

Well, come to think of it, this is actually supported for things like WiFi...

Maybe we should make this an option per-connector-type.