http://code.google.com/p/chromium/issues/detail?id=19270
(patches welcome!)
On Thu, Aug 13, 2009 at 3:35 PM, James Su <su...@chromium.org> wrote:
> Oh yes, you are right. So it might be safe to remove selectAll().
>
> Regards
> James Su
>
> 2009/8/14 Marshall Greenblatt <magreenbl...@gmail.com>
>
> 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
-~----------~----~----~----~------~----~------~--~---
