btzy / circuit-sandbox Goto Github PK

• PlayArea will only handle issues directly related to rendering
• Will need to consider how actions receive mouse events - whether they are constrained to playarea?

Notification display system

Display notification messages at the bottom-left of the play area. They have a translucent black background, and do not capture mouse events (i.e. mouse events pass through the notification display and are received by the play area).

There are two types of notifications:

1. Those that disappear automatically after 5 seconds
2. Those that are removed explicitly

Messages should be displayable in colour, just like the button bar description.

The notification display should support having multiple messages on display at the same time, and perhaps have simple animation like fade-out when the message needs to disappear.

(Type 1) Those that disappear automatically after 5 seconds include:

• "Saved to default clipboard" / "Saved to clipboard X"
• "Simulation reset"
• Error messages, e.g. "Can't redo" / "File already saved"

(Type 2) Those that are removed explicitly include:

• "Default view active"
• "Hold 'Shift' to add to selection; hold 'Alt' to subtract from selection"
• "Hold 'Shift' to draw a polyline"

Notification mode

We might want certain notifications to be only displayed in beginner mode. Two possible designs:

• The callers (e.g. SelectionAction) need to check if beginner mode in enabled, and thus decide whether to submit the notification
• The callers submit notifications with a 'notification mode' parameter, and the notification manager decides whether to display the notification, based on the notification mode and whether beginner mode is enabled

Type 2 notifications with RAII

It is useful for callers to use RAII to manage Type 2 notifications. Callers should construct a notification object to display the notification and destruct it to remove the notification. In this way, callers can never forget to remove a notification.

Have an "intelligent dragging" mode:
When moving a selection, extend or erase connecting wires as necessary to retain connectivity of connected components.

If undoing/redoing results in a change made to the circuit that lies outside the visible area, the viewport should be translated such that it can be seen. This behavior is implemented in various text editors, where the cursor is always kept within view and undoing/redoing positions the cursor to where the change was made.

Sometimes it is hard to position the mouse precisely where you need it to be.

Drawing over an element with the same element is a no-op but there is potential for more useful behavior. One possibility is to convert a logic gate or relay to a signal when clicking on it with the same tool. I suggest restricting this behavior to clicking so there is less chance of accidental conversions. As a bonus, double-clicking becomes an alternative way to draw signals.

This doesn't affect the functionality of the communicator, but they are all displayed in 'off' state to the user.

Clicking outside the selected area using no selected tool or using any tool (except the Panner and Selector) should exit selection mode.

• Need to design a protocol for reading and writing to files
• Should the bit-rate be adjustable (using Interact tool or something)?

Probably because SDL_RenderPresent() won't do vsync properly when minimized.

Ctrl-Shift-O can launch the clipboard dialog, followed by the file dialog if a clipboard is selected, to load a circuit file directly to a clipboard.

Settings for:

• Beginner mode
• Fullscreen
• UI scaling factor
• etc.

These settings are not expected to be changed very often, and should be persisted permanently.

Currently, after selecting a file for the file input communicator, a reset is required to start reading from the selected file.

This is because:

• Circuits should be allowed to assume that once the file communicator reports an EOF, there cannot be any more data from the file communicator;
• So the file communicator should not be allowed to load a new file while the circuit is in progress.

The most straightforward way to satisfy these requirements is to only load the selected files on reset, which is the current implementation.

Some possible alternatives that could be considered:

• Only allow loading a new file if the circuit has not received an EOF. (Issue: This behaviour might be unexpected by the user.)
• Have some way to signal the circuit about a new file being loaded. (Issue: More complex protocol means that the circuit has to be more complicated.)

Instead of telling the users they cannot step unless the simulator is paused, it might be better to disable the button outright while the simulator is running.

1. It is possible to change the cursor position without triggering mousemotion events by switching windows. This breaks several mousedown/mouseup events that depend on mousemotion updating the cursor position and functions like processMouseHover().
2. Mouseup events can be missed if the window loses focus from switching.

They seem to respond to keyboard events but not mouse events.

As more elements are implemented, it gets harder to identify a particular element in the play area by its color. Possible UI changes to make it easier to identify the hovered element:

• Display the name of the element in the button bar
• Highlight the name of the corresponding tool in the toolbar

• Support for storing multiple objects in the shared clipboard
• Interface to select the desired object

• Show error message if user entered invalid text
• Some obvious OK/Cancel buttons

Often, after pasting (Ctrl-V), the selection is not at the proper location and the user would need to move it. To move the selection, the user would need to click the Selector tool (if not already selected) and needs to click and drag the object.

It is much easier if the following behaviour is implemented: While the 'V' key is still held down, movement of the mouse will move the selection (similar to dragging when in selection mode), regardless of whether any mouse button is bound to the Selector tool.

This might lessen the need for #7. However, Ctrl-A probably shouldn't exhibit this behaviour because users expect a "select all" operation to preserve the state of the circuit, and it is easy to accidentally move the mouse. (On the other hand, Ctrl-V pastes from the clipboard, which doesn't have a 'proper' position on the circuit until it is pasted, so this behaviour will not surprise a user who accidentally moves the mouse.)

Users should be able to associate a short text string with any element.

1. Open an instance of Circuit Sandbox.
2. Write to a clipboard.
3. Open another instance of Circuit Sandbox.
4. Close the first instance.
5. Open another instance of Circuit Sandbox. This new instance might not be able to read the data saved by the first instance.

See how Boost.Interprocess and shm_unlink works.

The reset button is missing from the button bar.

To reproduce:

1. Select an element from the toolbox using the primary mouse button
2. Draw something on the canvas (so that opening a file will launch a new instance)
3. Press Ctrl-O
4. Double click a file to open
5. Original canvas has a pixel drawn at the location that was double clicked

Single click, then press the "Open" button does not cause this issue.

This tool should toggle element state immediately, regardless of whether the simulator is running.

Tool should be able to:

• Toggle logic level or logic gate or communicator
• Toggle conductiveness of relay

The new button should be functionally equivalent to what space currently does. Clicking on the button should also toggle its icon.

Currently, a square is drawn at the top left corner when default view is active. This should be changed to a border in playarea or something nicer.

Currently SDL_ShowSimpleMessageBox is used in the simulation speed dialog to report input errors. There might be other places where such a message box might be useful. It might be nicer to fit the theme of Circuit Sandbox, and have such message box look like the simulation speed dialog, instead of using the OS native dialog.

Circuit Sandbox needs an application icon. Application icons range from 1616 to 256256 or more, and are displayed in several places (e.g. title bar, desktop shortcut). It is possible for larger/smaller icons to use a different image.

Currently, communicator instances are shared across all history canvases. It might be necessary for the CanvasState stored in the history to have a different type from the current CanvasState.

Also, we might want to review the current CanvasState and savefile data to align with immediate propagation. In immediate propagation, we only use the logic levels of logic gates/sources/communicators and relay state of relays. For display purposes we also use the transmit state of communicators. All other logic states are not used at all. Currently, logic levels of all elements are saved, but relay state and communicator transmit state is not saved.

Add build instruction

• Select logically connected areas (that need not be a rectangle), instead of selecting a whole rectangle. Selection area need not be a rectangle.
• Support Shift-Click to select multiple areas?

Each logical screen communicator should be able to store a customizable colour, so that the circuit may contain screen communicators of arbitrary colours.

This would likely cause the save-file format to be changed in a way that cannot be loaded in earlier versions of Circuit Sandbox.

As clipboards (both the default and numbered ones) hold CanvasState to represent their the clipboard data, file referenced by communicators that only exist in the clipboards are held open. This might be un-intuitive to the user.

Possible fix: Make the clipboards store HistoryCanvasState instead of CanvasState. The file communicators in HistoryCanvasState will lose their backing communicators (and referenced files) if no CanvasState holds the same backing communicator (which means that the current canvas does not contain that backing communicator.

This is incongruous to the default clipboard functionality (Ctrl-C/Ctrl-V) where we don't automatically exit selection mode.

The current pencil tool which enables free form drawing is not ergonomic for circuit design. We should optimize the pencil tool for drawing horizontal and vertical lines.

• Distinct element type for inputs, which can be turned on (acts as a Source) or off (acts as a Conductive Wire)
• A way to toggle the on/off state of these elements

• Also, the zoom level should be set appropriately so that all parts of the save is visible.

There are two ways to enter selection mode without needing the selector to be bound (ctrl-V and ctrl-A).

If a user wanted to move the selection in this situation, they would have to

1. explicitly bind the selector
2. move the selection
3. and optionally rebind the previous tool
   which is quite troublesome for such a simple and common operation.

Possible solution:
Temporarily bind m1 and m2 to selector and panner and restore the previous tools when exiting selection mode. There are some interactions that have to be sorted out before this solution is implemented. For example, what should happen if the user tries to bind another tool before exiting selection mode? What if the selector or panner is already bound to m3?

This behaviour is more intuitive when the user wants to keep using the extended pencil mode, as the user does not need to think about releasing the Shift key just before clicking the last point

Just like the extended copy, extended cut should do something similar.