Closed
Bug 976969
Opened 11 years ago
Closed 7 years ago
Add TV module in gecko/dom
Categories
(Firefox OS Graveyard :: General, defect)
Firefox OS Graveyard
General
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: zouhc, Unassigned)
References
Details
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 Steps to reproduce: Add TV module for firefox os; Actual results: 1.the core of code implement in gecko/dom dir; 2.we just add tv api using webidl now, the real implement will commit soon; 3.make tv as an attribute of the navigator, app call it like this: navigator.tvManager 4.tv has some submodules, e.g, sound, pictue, channel. app call it like this: navigator.tvManager.soundManager Expected results: we hope mozilla can accept these code as the standard of tv of firefox os.
Comment 1•11 years ago
|
||
We usually discuss APIs a bit (on the https://lists.mozilla.org/listinfo/dev-webapi mailing list) before landing massive patches.
Updated•11 years ago
|
Keywords: dev-doc-needed
Comment 2•11 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #1) > We usually discuss APIs a bit (on the > https://lists.mozilla.org/listinfo/dev-webapi mailing list) before landing > massive patches. after discussion , it's nice to ask reviews if you want your patch to be taken into account.
we will provide dev-doc soon.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
have add a new topic in https://groups.google.com/forum/?hl=zh-CN#!topic/mozilla.dev.webapi/bRy0ECh_c-k,welcome you join.
have add a new topic in https://groups.google.com/forum/?hl=zh-CN#!topic/mozilla.dev.webapi/bRy0ECh_c-k
Updated•11 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → WONTFIX
Updated•11 years ago
|
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Updated•11 years ago
|
Status: REOPENED → NEW
Add dev webapi doc.
Attachment #8384445 -
Flags: ui-review+
Attachment #8384445 -
Flags: review+
Comment 7•11 years ago
|
||
Comment on attachment 8384445 [details]
TV-WebAPI-doc
This patch has not received any review.
Attachment #8384445 -
Flags: ui-review+
Attachment #8384445 -
Flags: review+
Comment 8•11 years ago
|
||
Hi Super Zou, this is an awesome work but I'd like to clarify some points before moving forward. 1. I just quickly looked though the API proposal and it seems to me that the you're hoping to include all the TV-related functionalities into Web APIs in the first place, which are: interface TVManager{ [Throws] readonly attribute TVCiManager ciManager; [Throws] readonly attribute TVCommonManager commonManager; [Throws] readonly attribute TVScanManager scanManager; [Throws] readonly attribute TVSoundManager soundManager; [Throws] readonly attribute TVPictureManager pictureManager; [Throws] readonly attribute TVChannelManager channelManager; [Throws] readonly attribute DtvAudioInfo dtvAudioInfo; }; Could you please give us some brief descriptions about these modules respectively? It's somehow difficult to guess the meanings by looking at the module/function names. 2. Do you have any concrete user cases about the need of these Web API from the apps' points of view? I'm asking this is I wonder some functions don't have to be public because the platform can just handle them internally. For example, why apps need TVScanManager to be able to scan the channels? Isn't that something the TV system can take care of during its initialization and the apps only need to know how to switch channels? 3. Regarding the TVSoundManager, since FirefoxOS is not just only designed for TVs, all the other devices that have speakers might need this function too. I think we somehow need to make these APIs more generic. We already had SpeakerManager[1] and AudioChannels[2] which might be a good entry point to start with. TVPictureManager might have the same issue, we probably need a more generic API to support various devices that have screens. 4. I'd suggest let's split up the modules into individual bug separately, it's hard to go through all the reviews (including Web IDL and implementations) in a single super big bug. 5. It's impossible keep the *TCL* terms as the enum names in the Web IDL. Web IDLs have to work for public. [1] https://wiki.mozilla.org/WebAPI/SpeakerManager [2] https://wiki.mozilla.org/WebAPI/AudioChannels
Comment 9•11 years ago
|
||
Hi super-zou, Thanks for contributing. Some comments about your patch: - The patch is quite large and thus hard to review. Maybe you can split it up into multiple pieces and get each piece reviewed individually. If possible, try to get the basic functionally reviewed first, and extras in separate patch later. - What are all these empty interfaces for? The comment says its for backward compatibility, but I don't expect that empty interfaces would make it through a review. - We'd really need some back-end code to make any use of this interface. There are Marionette test cases in the patch (they should be reviewed separately, btw) and it would be great to have a backend that's generic enough to do some testing in our emulator.
Reporter | ||
Comment 10•11 years ago
|
||
(In reply to Gene Lian [:gene] (work week Mar. 5 ~ Mar. 7) from comment #8) > Hi Super Zou, this is an awesome work but I'd like to clarify some points > before moving forward. > > 1. I just quickly looked though the API proposal and it seems to me that the > you're hoping to include all the TV-related functionalities into Web APIs in > the first place, which are: > > interface TVManager{ > [Throws] readonly attribute TVCiManager ciManager; > [Throws] readonly attribute TVCommonManager commonManager; > [Throws] readonly attribute TVScanManager scanManager; > [Throws] readonly attribute TVSoundManager soundManager; > [Throws] readonly attribute TVPictureManager pictureManager; > [Throws] readonly attribute TVChannelManager channelManager; > [Throws] readonly attribute DtvAudioInfo dtvAudioInfo; > }; > > Could you please give us some brief descriptions about these modules > respectively? It's somehow difficult to guess the meanings by looking at the > module/function names. > > 2. Do you have any concrete user cases about the need of these Web API from > the apps' points of view? I'm asking this is I wonder some functions don't > have to be public because the platform can just handle them internally. For > example, why apps need TVScanManager to be able to scan the channels? Isn't > that something the TV system can take care of during its initialization and > the apps only need to know how to switch channels? > > 3. Regarding the TVSoundManager, since FirefoxOS is not just only designed > for TVs, all the other devices that have speakers might need this function > too. I think we somehow need to make these APIs more generic. We already had > SpeakerManager[1] and AudioChannels[2] which might be a good entry point to > start with. TVPictureManager might have the same issue, we probably need a > more generic API to support various devices that have screens. > > 4. I'd suggest let's split up the modules into individual bug separately, > it's hard to go through all the reviews (including Web IDL and > implementations) in a single super big bug. > > 5. It's impossible keep the *TCL* terms as the enum names in the Web IDL. > Web IDLs have to work for public. > > [1] https://wiki.mozilla.org/WebAPI/SpeakerManager > [2] https://wiki.mozilla.org/WebAPI/AudioChannels For Q1: We will write the doc followwing the format of WebAPI/SpeakerManager, it contains some brief descriptions and user cases. For Q2: As a TV system, should supply the functions for users to scan channels manullay or automatically. For Q3: Yes, we will review some APIs, on the base of firefox os' existing webAPIs,merge the overlapping part. For Q4&Q5: This is our following treatment.
Reporter | ||
Comment 11•11 years ago
|
||
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #9) > Hi super-zou, > > Thanks for contributing. Some comments about your patch: > > - The patch is quite large and thus hard to review. Maybe you can split it > up into multiple pieces and get each piece reviewed individually. If > possible, try to get the basic functionally reviewed first, and extras in > separate patch later. > > - What are all these empty interfaces for? The comment says its for > backward compatibility, but I don't expect that empty interfaces would make > it through a review. > > - We'd really need some back-end code to make any use of this interface. > There are Marionette test cases in the patch (they should be reviewed > separately, btw) and it would be great to have a backend that's generic > enough to do some testing in our emulator. Thanks for your suggestion! We will split the patch into independent pieces and add some brief descriptions and user cases.
Comment 12•11 years ago
|
||
We have some internal discussion about TVCiManager/TVPictureManager. We think these features can directly be controlled by the Settings API. We don't really need to add new APIs for them. Specifically, for TVCiManager, apps will only read it instead of writing it, because platform will be in charge of the setting. For TVPictureManager, apps will change the settings' value and platform will communicate with the hardware based on the changed value.
Comment 13•11 years ago
|
||
I thought there was a move away from the Settings API? You even started the discussion: https://groups.google.com/forum/#!searchin/mozilla.dev.webapi/settings/mozilla.dev.webapi/Cqbs6bZTK1Y/9C1ckK4qlUMJ
Reporter | ||
Comment 14•11 years ago
|
||
(In reply to Gene Lian [:gene] (work week Mar. 5 ~ Mar. 7) from comment #12) > We have some internal discussion about TVCiManager/TVPictureManager. We > think these features can directly be controlled by the Settings API. We > don't really need to add new APIs for them. Specifically, for TVCiManager, > apps will only read it instead of writing it, because platform will be in > charge of the setting. For TVPictureManager, apps will change the settings' > value and platform will communicate with the hardware based on the changed > value. Hi Gene Lian, These APIs we supplied are mainly proprietary for TV device(ATV/DTV)'s Settings menu, the TV device is more complicated than other device and B2G's existing APIs can not satisfy it. For example, TV device needs set scene,mode and SRS effect of sound, but B2G's sound APIs don't have these APIs. TV has multi-input source, like ATV ,DTV, PC,Ypbpr, HDMI and so on, user possibly switch the source,each source should manage its own settings, but B2G system didn't think about it now.
Updated•9 years ago
|
Blocks: TV_FxOS2.5
Updated•9 years ago
|
No longer blocks: TV_FxOS2.5
Comment 15•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 11 years ago → 7 years ago
Resolution: --- → WONTFIX
Updated•7 years ago
|
Keywords: dev-doc-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•