Confirmed users
1,100
edits
Canuckistani (talk | contribs) |
Canuckistani (talk | contribs) |
||
Line 45: | Line 45: | ||
=== Top Priorities === | === Top Priorities === | ||
# Land SDK APIs in Firefox | # [https://github.com/mozilla/addon-sdk/wiki/JEP-SDK-in-Firefox Land SDK APIs in Firefox] | ||
# [https://wiki.mozilla.org/Features/Jetpack/Jetpack-Move-Widgets-to-top Move Add-ons to top of browser]. For a while we have talked about moving the widgets and panels the SDK provides to the top of the browser and away from the small add-on bar at the bar. The UX team agrees with this move and has given us some guidance to go ahead and make this move. | # [https://wiki.mozilla.org/Features/Jetpack/Jetpack-Move-Widgets-to-top Move Add-ons to top of browser]. For a while we have talked about moving the widgets and panels the SDK provides to the top of the browser and away from the small add-on bar at the bar. The UX team agrees with this move and has given us some guidance to go ahead and make this move. | ||
# [https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_as_an_Addon Add-on SDK as an Add-on] We currently ship the Add-on SDK as a zip file or source code through github. This may not be the best way for us to distribute the SDK. First, we have a built-in automated update mechanism with AMO which also provides support for stable and beta distribution channels. Second, if we can get the SDK to package itself we have a chance for SDK developers to "eat their own dogfood" - testing the packaging and perfomance everyday. Finally, possibly building upon the original prototype as well as Alexandre Poirot's work of porting the SDK to an add-on we can start to offload some of the Builder's time-consuming functions to the client while also avoiding difficult dependencies for Add-on SDK users. | # [https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_as_an_Addon Add-on SDK as an Add-on] We currently ship the Add-on SDK as a zip file or source code through github. This may not be the best way for us to distribute the SDK. First, we have a built-in automated update mechanism with AMO which also provides support for stable and beta distribution channels. Second, if we can get the SDK to package itself we have a chance for SDK developers to "eat their own dogfood" - testing the packaging and perfomance everyday. Finally, possibly building upon the original prototype as well as Alexandre Poirot's work of porting the SDK to an add-on we can start to offload some of the Builder's time-consuming functions to the client while also avoiding difficult dependencies for Add-on SDK users. | ||
# Developer Tools extensibility. In 2012 there has been a steady trickle of add-ons & experiments around extending the Firefox developer tools ( [http://vimeo.com/39627655 LiveScratchpad], [https://github.com/Gozala/scratch-kit/ Scratch Kit], [http://paulrouget.com/e/jsterm/ JSTerm], [https://wiki.mozilla.org/DevTools/Features/GCLI GCLI], etc ). As well, some of the greatest leaps forward for Firefox in popularity in particular with web developers centered around the ability to extend the platform and create developer tools. This project will see the Jetpack team working closely with the Developer Tools team to make it very easy to extend Firefox's developer tools to fit very specific developer needs. | |||
== SDK API Development == | == SDK API Development == |