Bug 107382 - Make SpeechSynthesis compile in the Chromium port
Summary: Make SpeechSynthesis compile in the Chromium port
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dominic Mazzoni
URL:
Keywords:
Depends on:
Blocks: 106742
  Show dependency treegraph
 
Reported: 2013-01-19 14:53 PST by Dominic Mazzoni
Modified: 2013-01-20 22:15 PST (History)
3 users (show)

See Also:


Attachments
Patch (7.22 KB, patch)
2013-01-19 15:07 PST, Dominic Mazzoni
no flags Details | Formatted Diff | Diff
Patch (7.32 KB, patch)
2013-01-20 14:35 PST, Dominic Mazzoni
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dominic Mazzoni 2013-01-19 14:53:12 PST
Let's start by adding the necessary stub files and making it compile when the ENABLE_SPEECH_SYNTHESIS flag is enabled.
Comment 1 Dominic Mazzoni 2013-01-19 15:07:22 PST
Created attachment 183635 [details]
Patch
Comment 2 Sam Weinig 2013-01-19 16:24:39 PST
What is the intent of SpeechSynthesisChromium.cpp?  Why would there be something Chromium specific at this layer?
Comment 3 chris fleizach 2013-01-20 00:09:44 PST
Comment on attachment 183635 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=183635&action=review

> Source/WebCore/Modules/speech/chromium/SpeechSynthesisChromium.cpp:48
> +}

i think we'll be able to move some of these calls into the SpeechSynthesis.h (i've done that in my latest patch), but I can move that around as needed

> Source/WebCore/WebCore.gypi:901
> +            'Modules/speech/DOMWindowSpeechSynthesis.cpp',

this might not be in alpha order

> Source/WebKit/chromium/features.gypi:110
> +      'ENABLE_SPEECH_SYNTHESIS=0',

looks like this is not in alpha order. should be after enable_smooth
Comment 4 Adam Barth 2013-01-20 00:29:01 PST
(In reply to comment #2)
> What is the intent of SpeechSynthesisChromium.cpp?  Why would there be something Chromium specific at this layer?

Presumably for the same reason there's something Mac-specific: http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/speech/mac/SpeechSynthesisMac.mm
Comment 5 Sam Weinig 2013-01-20 13:38:42 PST
(In reply to comment #4)
> (In reply to comment #2)
> > What is the intent of SpeechSynthesisChromium.cpp?  Why would there be something Chromium specific at this layer?
> 
> Presumably for the same reason there's something Mac-specific: http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/speech/mac/SpeechSynthesisMac.mm

I see.  If there is something that needs to be platform specific, it should be in the platform directory.
Comment 6 Dominic Mazzoni 2013-01-20 14:05:43 PST
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > What is the intent of SpeechSynthesisChromium.cpp?  Why would there be something Chromium specific at this layer?
> > 
> > Presumably for the same reason there's something Mac-specific: http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/speech/mac/SpeechSynthesisMac.mm
> 
> I see.  If there is something that needs to be platform specific, it should be in the platform directory.

It seems like a pretty common pattern to have platform-specific subdirectories inside of WebCore modules, e.g.:

accessibility/[atk,chromium,mac,etc.]
editing/[blackberry,chromium,mac,qt,etc.]
history/[blackberry,mac,qt,etc.]
Modules/filesystem/chromium

Is this pattern discouraged now, and is there a meta-bug to refactor all of the existing cases? If not, I'd rather stay consistent with similar code, and in particular for an optional module like this, I think it's more readable to keep all of the platform implementations together.

- Dominic
Comment 7 Sam Weinig 2013-01-20 14:25:23 PST
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #2)
> > > > What is the intent of SpeechSynthesisChromium.cpp?  Why would there be something Chromium specific at this layer?
> > > 
> > > Presumably for the same reason there's something Mac-specific: http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/speech/mac/SpeechSynthesisMac.mm
> > 
> > I see.  If there is something that needs to be platform specific, it should be in the platform directory.
> 
> It seems like a pretty common pattern to have platform-specific subdirectories inside of WebCore modules, e.g.:
> 
> accessibility/[atk,chromium,mac,etc.]
> editing/[blackberry,chromium,mac,qt,etc.]
> history/[blackberry,mac,qt,etc.]
> Modules/filesystem/chromium
> 
> Is this pattern discouraged now, and is there a meta-bug to refactor all of the existing cases? If not, I'd rather stay consistent with similar code, and in particular for an optional module like this, I think it's more readable to keep all of the platform implementations together.
> 
> - Dominic

Its true that it is unfortunate that there are places where this is not true, but that should not stop us from getting it right going forward.
Comment 8 Dominic Mazzoni 2013-01-20 14:35:21 PST
Created attachment 183687 [details]
Patch
Comment 9 Sam Weinig 2013-01-20 21:11:29 PST
(In reply to comment #8)
> Created an attachment (id=183687) [details]
> Patch

You seemed to have ignored my feedback.  Platform specific parts should be implemented in WebCore/platform and the Mac part should fixed as well.
Comment 10 Adam Barth 2013-01-20 21:43:53 PST
> You seemed to have ignored my feedback.  Platform specific parts should be implemented in WebCore/platform and the Mac part should fixed as well.

Perhaps cfleizach would be willing to fix the Mac port.  It's unfortunate that you didn't give this feedback when the Mac code landed.
Comment 11 Adam Barth 2013-01-20 21:49:05 PST
Comment on attachment 183687 [details]
Patch

IMHO, this stub file is fine given that it's just fixing the compile.  We should refactor both the Chromium and Mac versions of this file before adding any actual code to either of them, however.

Sam is likely also asking for an extra layer of abstraction so that SpeechSynthesis.cpp can be implemented in terms of a common WebCore/platform API that's agnostic as to which platform backend is actually implementing the synthesis.
Comment 12 Dominic Mazzoni 2013-01-20 22:05:36 PST
I filed https://bugs.webkit.org/show_bug.cgi?id=107414 for the refactoring. Sam, please help address some of my questions there and then I'll be happy to work on this, both Chromium and Mac parts.
Comment 13 WebKit Review Bot 2013-01-20 22:15:02 PST
Comment on attachment 183687 [details]
Patch

Clearing flags on attachment: 183687

Committed r140297: <http://trac.webkit.org/changeset/140297>
Comment 14 WebKit Review Bot 2013-01-20 22:15:06 PST
All reviewed patches have been landed.  Closing bug.