Small changes such as spacing and adding [in/out] identifiers after @params.

Small changes such as spacing and adding [in/out] identifiers after @params.
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=97004

[dmichael (off chromium), 2011-08-12 20:17:59]

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/image_data.h
File ppapi/cpp/image_data.h (left):

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/image_data.h#oldcode51
ppapi/cpp/image_data.h:51: ///
I thought brettw asked you in some other CL to add carriage returns in places
like this to make the source file more readable?  I don't care a whole lot, but
do you remember? I wouldn't want to undo something that he thought would help
readability.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h
File ppapi/cpp/input_event.h (right):

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcode24
ppapi/cpp/input_event.h:24: /// this object through the
<code>HandleInputEvent</code> on the
HandleInputEvent()?
Probably should either remove 'the' or add 'method' after HandleInputEvent(),
too.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcode31
ppapi/cpp/input_event.h:31: /// @code
This still looks super weird to me. Can we resolve the question soon, so you
don't add more inconsistent @code tags you'll need to clean up later?

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcode49
ppapi/cpp/input_event.h:49: /// This constructor constructs an input event from
the provided input event
What's wrong with 'given'? I don't care particularly, but you're changing it in
a bunch of places, and it doesn't really seem better to me... 'given' is used
all the time when describing function parameters. Probably because most
programmers have some math background, I guess.  I wouldn't bother changing it
if it was me.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcode59
ppapi/cpp/input_event.h:59: /// object. This function is valid for all input
events.
You can delete the last sentence; it's a holdover from an early version of the
interface and doesn't really make sense now.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcod...
ppapi/cpp/input_event.h:160: /// is_null().
missing param? I think it's okay either way, but you did it for keyboard events
below and mouse events above.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcod...
ppapi/cpp/input_event.h:163: /// Constructs a wheel input even from the given
parameters.
you added params for the analogous Mouse constructor above. We should probably
be consistent.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcod...
ppapi/cpp/input_event.h:192: /// GetScrollByPage() returns the number of
"clicks" of the scroll wheel
GetScrollByPage->GetTicks

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcod...
ppapi/cpp/input_event.h:231: /// Constructs a keyboard input even from the given
parameters.
Ditto about params fields; we should probably be consistent.

[jond, 2011-08-12 20:50:59]

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/image_data.h
File ppapi/cpp/image_data.h (left):

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/image_data.h#oldcode51
ppapi/cpp/image_data.h:51: ///
Yes, in fact, I shouldn't have changed this...

On 2011/08/12 20:17:59, dmichael wrote:
> I thought brettw asked you in some other CL to add carriage returns in places
> like this to make the source file more readable?  I don't care a whole lot,
but
> do you remember? I wouldn't want to undo something that he thought would help
> readability.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h
File ppapi/cpp/input_event.h (right):

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcode24
ppapi/cpp/input_event.h:24: /// this object through the
<code>HandleInputEvent</code> on the
On 2011/08/12 20:17:59, dmichael wrote:
> HandleInputEvent()?
> Probably should either remove 'the' or add 'method' after HandleInputEvent(),
> too.

Done.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcode31
ppapi/cpp/input_event.h:31: /// @code
Sure. Josie is back on Monday.

On 2011/08/12 20:17:59, dmichael wrote:
> This still looks super weird to me. Can we resolve the question soon, so you
> don't add more inconsistent @code tags you'll need to clean up later?

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcode49
ppapi/cpp/input_event.h:49: /// This constructor constructs an input event from
the provided input event
I believe the word "given" is improperly used in these places. I'll double
check, but, if anything, its a personal preference and it likely won't localize
well if we ever localize our docs. 

On 2011/08/12 20:17:59, dmichael wrote:
> What's wrong with 'given'? I don't care particularly, but you're changing it
in
> a bunch of places, and it doesn't really seem better to me... 'given' is used
> all the time when describing function parameters. Probably because most
> programmers have some math background, I guess.  I wouldn't bother changing it
> if it was me.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcode59
ppapi/cpp/input_event.h:59: /// object. This function is valid for all input
events.
On 2011/08/12 20:17:59, dmichael wrote:
> You can delete the last sentence; it's a holdover from an early version of the
> interface and doesn't really make sense now.

Done.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcod...
ppapi/cpp/input_event.h:160: /// is_null().
On 2011/08/12 20:17:59, dmichael wrote:
> missing param? I think it's okay either way, but you did it for keyboard
events
> below and mouse events above.

Done.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcod...
ppapi/cpp/input_event.h:163: /// Constructs a wheel input even from the given
parameters.
On 2011/08/12 20:17:59, dmichael wrote:
> you added params for the analogous Mouse constructor above. We should probably
> be consistent.

Done.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcod...
ppapi/cpp/input_event.h:163: /// Constructs a wheel input even from the given
parameters.
On 2011/08/12 20:17:59, dmichael wrote:
> you added params for the analogous Mouse constructor above. We should probably
> be consistent.

Done.

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcod...
ppapi/cpp/input_event.h:231: /// Constructs a keyboard input even from the given
parameters.
On 2011/08/12 20:17:59, dmichael wrote:
> Ditto about params fields; we should probably be consistent.

Done.

[dmichael (off chromium), 2011-08-12 21:32:37]

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h
File ppapi/cpp/input_event.h (right):

http://codereview.chromium.org/7617018/diff/16/ppapi/cpp/input_event.h#newcode49
ppapi/cpp/input_event.h:49: /// This constructor constructs an input event from
the provided input event
On 2011/08/12 20:50:59, jond wrote:
> I believe the word "given" is improperly used in these places. I'll double
> check, but, if anything, its a personal preference and it likely won't
localize
> well if we ever localize our docs. 
> 
> On 2011/08/12 20:17:59, dmichael wrote:
> > What's wrong with 'given'? I don't care particularly, but you're changing it
> in
> > a bunch of places, and it doesn't really seem better to me... 'given' is
used
> > all the time when describing function parameters. Probably because most
> > programmers have some math background, I guess.  I wouldn't bother changing
it
> > if it was me.
> 
Yeah, makes sense. There is a sense of the word Given that is right and is
common in this context, but can easily be read differently (I think you're
thinking of 'a given' as opposed to 'the given'). I doubt we'll ever localize
code documentation, but 'given' could still be confusing to ESL readers I guess.
Works for me.

http://codereview.chromium.org/7617018/diff/14002/ppapi/cpp/input_event.h#new...
ppapi/cpp/input_event.h:173: /// right (where the content moves up or left) is
represented as positive
[in]?

http://codereview.chromium.org/7617018/diff/14002/ppapi/cpp/input_event.h#new...
ppapi/cpp/input_event.h:182: /// only generate integer scroll amounts. But
fractional values are also
What's the asterisk mean here? Is that intentional?

http://codereview.chromium.org/7617018/diff/14002/ppapi/cpp/input_event.h#new...
ppapi/cpp/input_event.h:183: /// possible, for example, on some trackpads and
newer mice that don't have
you have an extra 'user'

http://codereview.chromium.org/7617018/diff/14002/ppapi/cpp/input_event.h#new...
ppapi/cpp/input_event.h:272: 
Oops, everything after the first sentence is wrong now in the new API. Please
delete all but the first sentence. In fact...  the first sentence should
probably be tweaked a little:
'This value represents the typed character as a UTF-8 string.'

[jond, 2011-08-15 17:32:11]

http://codereview.chromium.org/7617018/diff/14002/ppapi/cpp/input_event.h
File ppapi/cpp/input_event.h (right):

http://codereview.chromium.org/7617018/diff/14002/ppapi/cpp/input_event.h#new...
ppapi/cpp/input_event.h:173: /// @param modifiers A bit field combination of the
On 2011/08/12 21:32:37, dmichael wrote:
> [in]?

Done.

http://codereview.chromium.org/7617018/diff/14002/ppapi/cpp/input_event.h#new...
ppapi/cpp/input_event.h:182: /// @param[in] scroll_by_page * When true, the user
is requesting to scroll
On 2011/08/12 21:32:37, dmichael wrote:
> What's the asterisk mean here? Is that intentional?

Done.

http://codereview.chromium.org/7617018/diff/14002/ppapi/cpp/input_event.h#new...
ppapi/cpp/input_event.h:183: /// by pages. When false, the user user is
requesting to scroll by lines.
On 2011/08/12 21:32:37, dmichael wrote:
> you have an extra 'user'

Done.

http://codereview.chromium.org/7617018/diff/14002/ppapi/cpp/input_event.h#new...
ppapi/cpp/input_event.h:272: /// null-termianted UTF-8 string.
On 2011/08/12 21:32:37, dmichael wrote:
> Oops, everything after the first sentence is wrong now in the new API. Please
> delete all but the first sentence. In fact...  the first sentence should
> probably be tweaked a little:
> 'This value represents the typed character as a UTF-8 string.'

Done.

[dmichael (off chromium), 2011-08-16 15:34:03]

LGTM