Re: [UndoManager] Disallowing live UndoManager on detached nodes

On Fri, Aug 24, 2012 at 1:41 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:

> 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.
>

Just to clarify, I'm not saying that IE/WebKit behavior is better since
this is basically a matter of opinion. Wearing the editor's hat, what I'm
interested here is to come up with an API that can accommodate both
behaviors, not to pick a single behavior.

- Ryosuke

Received on Friday, 24 August 2012 20:49:23 UTC