On Thu, Aug 13, 2009 at 1:07 PM, Darin Fisher <da...@chromium.org> wrote:
> Hmm... take a look at EditorCommands.cpp. The executeSelectAll method just
> calls frame->selection()->selectAll(). That's the same method that
> WebFrameImpl::selectAll() calls.
I just verified this in the debugger -- the Frame pointer is the same in
both cases.
>
> -Darin
>
>
> On Thu, Aug 13, 2009 at 10:05 AM, Darin Fisher <da...@chromium.org> wrote:
>
>> Oh, good catch. If that is indeed the case, then eliminating
>> WebFrame::selectAll would be a mistake.-Darin
>>
>>
>> On Thu, Aug 13, 2009 at 9:58 AM, James Su <su...@chromium.org> wrote:
>>
>>> If I understand correctly, selectAll() and executeCommand("SelectAll")
>>> are different. The first one selects all text in the frame, while the second
>>> one selects all text in an editor (input box).
>>>
>>> Regards
>>> James Su
>>>
>>> 2009/8/14 Darin Fisher <da...@chromium.org>
>>>
>>>> Yeah, I agree. Those are problems. However, the intent is to match
>>>> the set of commands reachable by script. The values for execCommand are
>>>> "well known".
>>>>
>>>> I also worry about having to keep the WebKit API in sync with WebCore.
>>>>
>>>> I agree that selectAll should be dropped in favor of
>>>> executeCommand("SelectAll").
>>>>
>>>> -Darin
>>>>
>>>>
>>>> On Thu, Aug 13, 2009 at 8:49 AM, Marshall Greenblatt <
>>>> magreenbl...@gmail.com> wrote:
>>>>
>>>>> On Wed, Aug 12, 2009 at 5:49 PM, Darin Fisher <da...@chromium.org>wrote:
>>>>>
>>>>>> Yes, sorry about that. Please see render_view.cc. They are just
>>>>>> implemented using WebFrame::executeCommand.
>>>>>
>>>>>
>>>>> Ah, I see. As an API consumer I would prefer to have separate methods
>>>>> for each supported command, or have executeCommand() take an enumeration
>>>>> instead of a string argument. These are my qualms about the current
>>>>> executeCommand() approach:
>>>>>
>>>>> 1. The set of available commands is non-obvious from viewing the
>>>>> WebFrame header file. Consumers of the API will need to keep track of
>>>>> WebCore internals (EditorCommand.cpp), which logically violates the API
>>>>> abstraction layer.
>>>>>
>>>>> 2. If the commands change, there is no compile-time notification to the
>>>>> API consumer.
>>>>>
>>>>> 3. It's not clear which commands are meaningful/useful for Chromium.
>>>>>
>>>>> 4. (nit) The current implementation is inconsistent -- selectAll() is
>>>>> functionally equivalent to executeCommand("SelectAll"), for instance.
>>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>>>> -Darin
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 12, 2009 at 1:58 PM, Marshall Greenblatt <
>>>>>> magreenbl...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Darin,
>>>>>>>
>>>>>>> The Undo(), Redo(), Cut(), Copy(), Paste() and Delete() methods were
>>>>>>> removed from WebFrame when the class moved to the public API. Is there
>>>>>>> currently a way to perform these actions?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marshall
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> >>>>
>>>>
>>>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
