Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Table of Contents
The swing package javax.swing.undo brings a rather easy to implement undo/redo support.
Though the Sun Tutorial is targeted mostly at text documents, it also works fine for graphics.
See the current JCurlShotPlanner for an example.
If the user can pick items to undo/redo from a command history the undo mechanism is called "non-linear" or "selective"<bibref>Berlage1994</bibref>.
- a list of all edits must be displayed (which is package private).
A common problem to all multi-user undo strategies is
Any multi-user application has to integrate all users' contributions into a consolidated "common" command history, be it centralised in one repository or distributed and redundant at multiple or all users' clients.
The solutions include
Does make no sense in this context (JCurlShotPlanner) as the clients usually run on separate hardware
Manages one exclusive, typically coarse grained lock, i.e. blocking any interaction from every user but the lockholder. This is not desireable as it
- drastically degrades the responsiveness of the application,
- is overly restrictive (for JCurlShotPlanner), as the 17 primary entities (16 initial rock positions plus shot target and speed) should be modifyable independently,
- still requires conflict resolution for mid-air collissions (aquire lock).
Doesn't make much sense, as a user might want to undo a remote change but keep a local one.
Situation: exactly what Chapter 2.5 "Undo in Multi-User Applications"<bibref>Berlage1994</bibref> analyses. That's what Collaborative Editing should aim for.
The desired solution for Collaborative Editing should have those characteristics:
- applicable for two or more users,
- high latency (WAN) tolerant,
- low bandwidth usage,
- minimal number of events,
- minimal locking,
- high responsiveness,
- support long running, session like edits (e.g. mouse drag operation),
- support short running, atomic edits (e.g. undo/redo operation),
- automatically resolve mid-air collissions in an way obvious to the user.
- optimistic or no locking (because 2., 5., 6.),
- no ACK but only failure responses (stay optimistic),
- non-mandatory "in edit" messages at the begin of a drag (mostly to support visual feedback and reduce mid-air collissions),
- a common virtual time<bibref>Ellis1989</bibref> (maybe a Lamport clock suffices?) and timestamped messages (for a common edit history),
- selective multi-user undo to support both global and local undo (Chapter 2.5, <bibref>Berlage1994</bibref>),
- message bookkeeping (numbering) to detect lost messages,
- prioritised users (or: session participants) to resolve mid-air collissions automatically.
Once more than two users communicate, a Lamport clock will not suffice to resolve all conflicts? If all messages are broadcasted to all users it will suffice in combination with user priorities to resolve simultaneous edits.
Read papers are <bibref>Berlage1993</bibref> <bibref>Berlage1994</bibref> <bibref>Munson1996</bibref> <bibref>Lamport1978</bibref>
Next come <bibref>Mattern1989</bibref> <bibref>Choudhary1992</bibref> <bibref>Kurlander1988</bibref> <bibref>Prakash1992</bibref> <bibref>Prakash1994</bibref>