Add fixed mode
ialokim opened this issue · comments
When playing with the digitaljs output, changing some input signals etc. it is often not really necessary to be able at the same time to delete and add wires or move cells or wires around.
I would propose to distinguish the two use cases "rearranging things nicely" and "manipulating and observing signals" in terms of adding a "fixed" mode where the nodes or wires would not be moved around. On the other hand, some sort of "edit" mode where signals are not changing (circuit simulation is stopped) could also be useful.
I guess we could differentiate between three modes: "edit", "simulate" and "both" (which would be equivalent to how it is working now). What do you think about this?
I'm a strong proponent of modeless user interfaces. Modes tend to be confusing to users - they need to learn what the modes are, how to recognize which mode is currently active, how to change modes, etc.
Currently, DigitalJS allows pausing the simulation, which is kinda like the "edit" mode you described (simulation is stopped, but you can still edit the circuit). In digitaljs_online, simulation is unpaused by default - the opposite would be confusing (you would need to know about it being paused, and how to unpause it).
I understand the possible need for "no-edit" mode in DigitalJS (for example, you could embed a simulation of a certain circuit on a page, and you don't want the user to mess around with it). This could be more fine-grained, for example you could distinguish "visual-only" edits (moving gates and links around) and "semantic-changing" edits (connecting and disconnecting links). But I don't know if I want this mode to be user visible in digitaljs_online. It doesn't seem to add value there, but it can create confusion.
I think this feature could be included in DigitalJS. I think it should be possible to handle this via JointJS.
Thanks for your extensive answer. I kind of agree on the point that too much options lead to confusion. Nevertheless, I would like to implement a fixed mode within digitaljs as you've suggested using JointJS options.
There is indeed the paper.setInteractivity() method which allows to disable part of or the whole interactivity of moving and editing the graph. But as you've defined custom cursor styles in your styles.css, these are not affected by the jointJS function.
Would be adding a class such as fixed to the paper and disabling pointer-events in this case using CSS the way to go? (Doesn't jointJS automatically handle cursor styles, e.g. on magnets?)
The cursor styles in styles.css does not seem to be much different from the defaults in JointJS (correct me if I'm wrong, i haven't touched this part for some time). I don't know if JointJS has automatic handling of cursor styles, a quick glance at the source code leads me to believe it does not. If that's the case, the proposed solution (by adding a CSS class to the paper) looks fine to me.
Another thing - this should probably be done paper-side, the circuit itself probably does need to know that the interface disallows editing.
Another thing - this should probably be done paper-side, the circuit itself probably does need to know that the interface disallows editing.
Sorry, I'm not sure if I get you right here. If it is paper-side, the circuit wouldn't know about it (but it probably wouldn't need so either, except in the case of displaying subcircuits where the proper css class should be added too on initialization). Btw, do circuits keep some record of "open subcircuits" to query for?
As you answered your doubts yourself, I assume you do get it right.
No, there is no record of open subcircuits. By the way, I'm generally not very happy on the pop-up window stuff in DigitalJS. Currently, displaying popups with subcircuits is handled in the Circuit class; the popup for memories is handled in the view. Ideally, these things should be handled externally. Some users might not want the popups; others might want something different (tabs, side panels, etc.).
not very happy on the pop-up window stuff in DigitalJS
That's something we already thought about too. I will open a new issue to track this idea.