On Thu, Aug 23, 2012 at 5:10 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Aug 23, 2012 at 4:32 PM, Glenn Maynard <glenn@zewt.org> wrote:
> > On Thu, Aug 23, 2012 at 12:19 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
> >>>
> >>> It is not worse either way. Equally bad both ways. But, we're
> designing a
> >>> new API here, so we should make the API as good as possible from the
> start.
> >>> And I think that means allowing multiple undo stack must be in. The
> >>> default handling could be somehow platform specific.
> >>
> >>
> >> Maybe I didn't make this point clear but we're not going to implement
> >> multiple undo managers in a single document (at least as it's currently
> >> spec'ed) in WebKit regardless of how useful that feature is. Our
> >> implementation feedback is that we can't implement it.
> >
> >
> > I'm a bit confused: first you said that UndoManager's default behavior
> > should be able to represent the platform's native convention (which means
> > handling Windows's undo-stack-per-input-field), and then that you're
> > effectively not going to implement anything but OSX's behavior (single
> undo
> > stack).
>
Not sure about Linux but there is no "default" behavior on Windows as I
have previously mentioned. All Windows app gets is WM_UNDO and WM_REDO. The
fact many applications let each text field have its own undo manager is the
artifact of them using "Edit" window class, not a platform convention. This
is also evident from the fact Microsoft Internet Explorer uses a single
undo manager for all text fields in the same document. As such, WebKit's
behavior to share the single undo manager follows the platform convention
on both Mac and Windows.
I'm probably missing something since I'm not familiar enough with
> > UndoManager; can you clarify?
>
> Right. Would it be possible for webkit to implement undoscope using a
> global undo manager? I.e. the global undo manager would be the one
> holding references to nodes, and the undoscope attribute is
> effectively only provides some API as well as affects which nodes are
> observed for automatic transactions.
>
We might be able to if we get rid of undo() and redo() from UndoManager
interface. The problem with these two methods is that they inserts/removes
new/existing entry at an arbitrary location in the undo stack if we had
single undo manager but NSUndoManager and QtUndoManager only support stack
operations (pop or push at the top of the undo stack). Also, supporting
these operations violate user expectations as described by Maciej.
- Ryosuke