A unified development experience

[Kevin Grandon]

Hi All,

It seems like there's been a lot of frustration expressed around our development environments. I thought I'd send out an email with some thoughts to see if we can spark a discussion to unify our development experience.

Just for comparison: iOS developers use *the* XCode emulator. Android developers use *the* android emulator. FFOS devs use r2d2b2g, b2g desktop, or FF nightly.

There's clearly a problem that we aren't focused on our developer offerings here. We don't have a single development experience which we offer as a product and is easily debugged. I think we can do a lot better, and in my mind we should be using the browser for all FFOS app development. There are several possible ways to implement this, here is what I'm currently thinking:

- Use a barebones Firefox install as our *only* supported emulator
- Support all WebAPIs fully. (Can the dialer make a call with WebRTC?)
- Support all system fonts, shared resources, building blocks.
- Perhaps the developer could launch the app by drag/dropping the manifest on firefox, or navigating to it.


There are stepping stones we could take to get to that point, but in my eyes that is the golden land. Please send your thoughts, and if there's interest, let's find a way to unify our developer offerings.

Thanks,
Kevin

[Stefan Arentz]

On 2013-02-06, at 2:12 PM, Kevin Grandon <kgra...@mozilla.com> wrote:

> Hi All,
>
> It seems like there's been a lot of frustration expressed around our development environments. I thought I'd send out an email with some thoughts to see if we can spark a discussion to unify our development experience.
>
> Just for comparison: iOS developers use *the* XCode emulator. Android developers use *the* android emulator. FFOS devs use r2d2b2g, b2g desktop, or FF nightly.
>
> There's clearly a problem that we aren't focused on our developer offerings here. We don't have a single development experience which we offer as a product and is easily debugged. I think we can do a lot better, and in my mind we should be using the browser for all FFOS app development. There are several possible ways to implement this, here is what I'm currently thinking:
>
> - Use a barebones Firefox install as our *only* supported emulator
> - Support all WebAPIs fully. (Can the dialer make a call with WebRTC?)
> - Support all system fonts, shared resources, building blocks.
> - Perhaps the developer could launch the app by drag/dropping the manifest on firefox, or navigating to it.

Some thoughts from a seasoned iOS developer who is just learning how to write Firefox OS applications :-)

It is not easy. Limited tooling is part of the challenge.

The Firefox OS Simulator is good to try out your app when you don't have a phone. But that is it. To use it for development is not a great experience because it is so bare bones. My workflow has been:

10 edit index.html
20 switch to firefox, find the simulator tab, hit the Update button for my app
30 find the B2G app because it does not automatically come to the foreground
40 wait until B2G.app is ready 'booting'. Try out my app. browse through the console.
50 GOTO 10

It works. But it is so basic and limited. Very frustrating.

Ideally we have all the B2G APIs available in a special mode of Firefox. Then I would like to boot Firefox OS in a tab, set the responsive layout to phone size and use all the awesome tools we have available there. The Web Console, Scratchpad, Inspector, Profiler and Developer Toolbar.

10 Open app in Firefox
20 edit index.html - save to auto reload in firefox
30 Use Developer Tools to inspect and debug.
40 GOTO 20

Also, I just want to hit Command-R to reload my app.

I know I'm raising the bar :-)

I'm also happy to talk about other issues that I am running into as a n00b FxOS app developer coming from the dark side.

S.

[ndesau...@mozilla.com]

Packaged app development sucks. We promise developers these shiny new
device API's*.

* You need to package it, you can't load it on the phone without going through
the marketplace review process which you can't do if the app is not done
(Catch 22), there's all these manifests, the API's aren't at least mocked out in FF, etc.

I feel like we're so concerned with security that packaged app development is
no longer usable. It's like being in a room where the only door is so secure
that no one may pass through it. That's great, but now you're trapped in
the room. I feel like this mistake was not learned from sync.
Security doesn't matter if no one's using it, and I believe somewhere around
the MV office, there's a poster that says life is too short to
build something no one wants.

I spend time working with third party app developers, partners for launch,
and they have such a difficult time developing packaged apps. I was asked
yesterday "is this the only way to do it?" regarding side loading packaged apps,
and unfortunately the answer is yes, with a side of headache. The biggest
disappointment I saw at our app hackdays was developer's enthused by our device
API's, then confusion around actually developing an app using them.

We should want to develop a platform that leads in developer tooling, one where
we enable developers to make awesome new apps that take advantage of the
hardware, but we've limited them for fear of a rogue app being able to talk up
all of our "anytime minutes."

Packaged app development sucks, and we need to fix that.

[Vivien]

On 06/02/2013 20:12, Kevin Grandon wrote:
> Hi All,
>
> It seems like there's been a lot of frustration expressed around our development environments. I thought I'd send out an email with some thoughts to see if we can spark a discussion to unify our development experience.
>
> Just for comparison: iOS developers use *the* XCode emulator. Android developers use *the* android emulator. FFOS devs use r2d2b2g, b2g desktop, or FF nightly.

Apps is not only for FFOS it is also for Firefox.

>
> There's clearly a problem that we aren't focused on our developer offerings here.

That's actually makes sense - there was no third party developers before
and nothing has been released yet. Also it does not seems the main role
of Gaia developers to do that - even if Gaia developers have spend a lot
of time making apps and can share many things.

There is a team at Mozilla dedicated to making third party developer
life easier but I'm not sure which mailing list they use.

> We don't have a single development experience which we offer as a product and is easily debugged. I think we can do a lot better, and in my mind we should be using the browser for all FFOS app development.

I agree 100%. In my secret dreams Firefox will be the only tool we need
and developers will have all the devtools for free and there will be a
devtool to generate a manifest, etc...

There are severals things to do and imho the best is to work closely
with the devtools team to make sure the default set of tools that come
with Firefox works for the Mobile as well.
Having a list of tools needed and a list of bugs where the devtools team
is included will help a lot here.

The first one in my mind is the remote web console working with remote
processes (https://bugzilla.mozilla.org/show_bug.cgi?id=797627).
Anything else you need?

> There are several possible ways to implement this, here is what I'm currently thinking:
>
> - Use a barebones Firefox install as our *only* supported emulator

That's a goal I share. That's actually quite easy for many apps. I would
like a way for device-width to be hackable in the responsive design mode.

> - Support all WebAPIs fully. (Can the dialer make a call with WebRTC?)

I feel like this is a call for the WebAPI team and you should include
them in the discussion instead of only dev-gaia.

Also I'm not 100% convinced that 'all' WebAPIs makes sense at all. For
example all the certififed apps are nice but since they won't be easily
accessible for third party apps user focusing on what apps authors will
be able to access seems better to me.

> - Support all system fonts, shared resources, building blocks.

Those are easy to support.

> - Perhaps the developer could launch the app by drag/dropping the manifest on firefox, or navigating to it.
>
>
> There are stepping stones we could take to get to that point, but in my eyes that is the golden land. Please send your thoughts, and if there's interest, let's find a way to unify our developer offerings.

A first step imo would be to make Gaia apps hackable in Firefox (again).
That would moves most of the Gaia devs back on the Firefox train. The
main trick here is permissions beeing broken, hacking
tools/extensions/httpd/bootstrap.js to do the same thing that
PermissionsInstaller.jsm in Gecko should do the trick.

I'm running out of battery but that sounds a sane discussion to have :)

> Thanks,
> Kevin
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[Dietrich Ayala]

On Wed, Feb 6, 2013 at 11:48 AM, Stefan Arentz <sar...@mozilla.com> wrote:
> Ideally we have all the B2G APIs available in a special mode of Firefox.

THIS would simplify things so much for developers, allowing so much
tool re-use, familiar environment, add-on extensibility, etc.

If Mozilla posits that these APIs are part of the Web, then enabling
them on desktop is part of proving that true.

I've asked a couple of people about this already:

* Some APIs around app install/uninstall/permissions/etc are highly
dependent on WebRT and related specialized code in Firefox OS,
requires some work.

* Some APIs wouldn't really work at all, but could be stubbed/mocked
out. Eg Telephony.

* Some APIs *could* work, like network management, but not a lot of
value to doing so, so should also be stubbed/mocked out.

IMO we should be bold in enabling these APIs in desktop Firefox,
available by setting a pref, so they're available for developers at
least.

[Fabrice Desre]

On 02/06/2013 12:31 PM, ndesau...@mozilla.com wrote:

> Packaged app development sucks. We promise developers these shiny new
> device API's*.
>
> * You need to package it, you can't load it on the phone without going through
> the marketplace review process which you can't do if the app is not done
> (Catch 22), there's all these manifests, the API's aren't at least mocked out in FF, etc.

You can sideload them on device without signing and going to the
marketplace. Harald has a Makefile and I wrote a firefox add-on that
does just that (https://github.com/fabricedesre/b2gremote - needs to be
updated for latests nightlies).

> I feel like we're so concerned with security that packaged app development is
> no longer usable. It's like being in a room where the only door is so secure
> that no one may pass through it. That's great, but now you're trapped in
> the room. I feel like this mistake was not learned from sync.
> Security doesn't matter if no one's using it, and I believe somewhere around
> the MV office, there's a poster that says life is too short to
> build something no one wants.

Hint: you can build stuff yourself, no need to ask anything to anyone.
People complaining about the security model *never* provided any
reasonable alternative.

> We should want to develop a platform that leads in developer tooling, one where
> we enable developers to make awesome new apps that take advantage of the
> hardware, but we've limited them for fear of a rogue app being able to talk up
> all of our "anytime minutes."

Not true. We're not there yet because of a lack of time and resources,
not because we limited anything on purpose. That's a very naive point of
view.

Fabrice
--
Fabrice Desr�
b2g team
Mozilla Corporation

[davidw...@gmail.com]

I've shared many of the same frustrations as some other developers above. In creating the Quick Start Guide (https://github.com/darkwing/firefoxos-quick-start) requested of me by Dev Ecosystem team, I ran into the following issues:

1. The Simulator we promote (https://marketplace.firefox.com/developers/docs/firefox_os_simulator) is well, well outdated. API support isn't current and once I uninstall an app, I need to reinstall the Simulator plugin to reinstall because the app icon never displays on the home screen again. Myk sent me an updated simulator but that doesn't do the public any good. We should really be updating this simulator on a more frequent basis.

2. API documentation is horribly lacking at the moment. The wiki page (https://wiki.mozilla.org/WebAPI) isn't ideal because in most cases it's nowhere near enough information to get started using said APIs, and the MDN page (https://developer.mozilla.org/en-US/docs/WebAPI) shows very little detail as well. It will be difficult to host a hack day when users don't know how to use the tools we've provided to them. We need to do a better job getting documentation completed; basic explanations of APIs with lots of code samples.

The thread started by addressing the dev stack issue, so a few ideas:

1. Being able to complete apps in Nightly would be ideal but I know that would be almost impossible from a technical standpoint. The APIs that can be exposed on desktop, however, should be.

2. I'm wondering if there's a tool we could create that could act similar to how FirebugLite did. Include a JS file in your app and it could act as a shortcut to re-install an app and do other similar functionalities.

3. Remote debugging would be epic.

Just a few thoughts from me.

> Fabrice Desr�
>
> b2g team
>
> Mozilla Corporation

[ndesau...@mozilla.com]

> Fabrice Desr�
>
> b2g team
>
> Mozilla Corporation

Fabrice,
I was wrong to accuse the security model without being fully aware of the reasons as to why packaged app development sucks. But that's what I'm trying to find out. I know you personally put a lot of time and hard work into it. Security models are way over my head, and I overstepped in referring to it as something unusable.

I'm not comfortable telling third party devs that we have an outdated tools that they are expected use to develop packaged apps. If people say FFOS sucks because they didn't get to use the device API's that we promised, then that will break my heart and I'm trying to prevent that.

[ndesau...@mozilla.com]

On Wednesday, February 6, 2013 11:12:39 AM UTC-8, Kevin Grandon wrote:

Packaged app development sucks. We promise developers these shiny new
device API's*.

* You need to package it, you can't load it on the phone without going through
the marketplace review process which you can't do if the app is not done
(Catch 22), there's all these manifests, the API's aren't at least mocked out in FF, etc.

I feel like we're so concerned with security that packaged app development is
no longer usable. It's like being in a room where the only door is so secure
that no one may pass through it. That's great, but now you're trapped in
the room. I feel like this mistake was not learned from sync.
Security doesn't matter if no one's using it, and I believe somewhere around
the MV office, there's a poster that says life is too short to
build something no one wants.

I spend time working with third party app developers, partners for launch,
and they have such a difficult time developing packaged apps. I was asked
yesterday "is this the only way to do it?" regarding side loading packaged apps,
and unfortunately the answer is yes, with a side of headache. The biggest
disappointment I saw at our app hackdays was developer's enthused by our device
API's, then confusion around actually developing an app using them.

We should want to develop a platform that leads in developer tooling, one where
we enable developers to make awesome new apps that take advantage of the
hardware, but we've limited them for fear of a rogue app being able to talk up
all of our "anytime minutes."

[davidw...@gmail.com]

I've shared many of the same frustrations as some other developers above. In creating the Quick Start Guide (https://github.com/darkwing/firefoxos-quick-start) requested of me by Dev Ecosystem team, I ran into the following issues:

1. The Simulator we promote (https://marketplace.firefox.com/developers/docs/firefox_os_simulator) is well, well outdated. API support isn't current and once I uninstall an app, I need to reinstall the Simulator plugin to reinstall because the app icon never displays on the home screen again. Myk sent me an updated simulator but that doesn't do the public any good. We should really be updating this simulator on a more frequent basis.

2. API documentation is horribly lacking at the moment. The wiki page (https://wiki.mozilla.org/WebAPI) isn't ideal because in most cases it's nowhere near enough information to get started using said APIs, and the MDN page (https://developer.mozilla.org/en-US/docs/WebAPI) shows very little detail as well. It will be difficult to host a hack day when users don't know how to use the tools we've provided to them. We need to do a better job getting documentation completed; basic explanations of APIs with lots of code samples.

The thread started by addressing the dev stack issue, so a few ideas:

1. Being able to complete apps in Nightly would be ideal but I know that would be almost impossible from a technical standpoint. The APIs that can be exposed on desktop, however, should be.

2. I'm wondering if there's a tool we could create that could act similar to how FirebugLite did. Include a JS file in your app and it could act as a shortcut to re-install an app and do other similar functionalities.

3. Remote debugging would be epic.

Just a few thoughts from me.



On Wednesday, February 6, 2013 4:12:17 PM UTC-6, Fabrice Desre wrote:

[ndesau...@mozilla.com]

On Wednesday, February 6, 2013 2:12:17 PM UTC-8, Fabrice Desre wrote:

> Fabrice Desr�
>
> b2g team
>
> Mozilla Corporation

[Bill Walker]

Kevin,

* On different kinds of developers: I agree that many native iOS and Android developers will expect Mozilla to give strong opinions about devtools, and some kind of integrated developer experience, and that we'll fare better with those folks if we can supply one. (I also bet many experienced web developers will ignore any SDK we provide them and just the tools they use now. That's the beauty of the web).

* On the need for a Firefox OS Simulator versus just developing in Desktop Firefox: I think one of your assumptions is that FFOS app developers don't need to see their app launch from a Gaia home screen nor try installing it from the Firefox Marketplace into Gaia, that they need to focus on designing for the right screen sizes, fonts, and WebAPI's. (If I got your idea wrong, I apologize).

I agree that most app developers don't _need_ Gaia running, but based on talking to lots of developers and reading their blogs, many of them _want_ it. And my feeling is, if they want it and it gets them excited about our ecosystem, then we should make it. That's why I've championed the work on r2d2b2g [1].

-Bill

[1] It's also the easiest place to have Apps running in the context of MozActivity, app security + permissions model, etc, etc.

On Wednesday, February 6, 2013 11:12:39 AM UTC-8, Kevin Grandon wrote:

[Tim Chien]

Few thoughts:

- totally agree that we should have a better developer offering.
- agree that OWAs are not just for Firefox OS, however that's not a reason
for us not to provide a Simulator, even if Firefox Desktop can provide all
the APIs. At the end of day people will need to test the interaction with
the phone UI, testing touch events, flow, and look-and-feel with a phone
like UI, to properly code their apps -- we will never be able to offer them
in Firefox Desktop.
- Small correction: System fonts is accessible to the apps, but building
blocks is not accessible to them. That's a huge issue which we haven't have
the time think through.
- I feel like all this is part of the package when we decided we should
roll out a packaged app model for Open Web Apps. I wonder why wasn't the
road map being planned out when that was decided?

I think we all agree that Ctrl+R or livereload is way better than
compilation or |make install-gaia|. Being able to iterate without having to
wait is THE BIGGEST advantage of web development. If we cannot get away
with build an Mozilla XCode(TM) for OWA development, at least we should
think of something to preserve that.

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>

--
Tim Guan-tin Chien, Senior Front-end Dev., Mozilla Corp. (Taiwan)

[robn...@gmail.com]

Hi,

Interesting to see this thread and the initiatives!
My thoughts:

- IF we do a separate version of Firefox it needs to have a separate profile by default, be able to run side-by-side with regular Firefox and more. For years, it seems like the solution has been to throw another version of Firefox into the mix, and then most developers just get sick of not being able to run multiple version simultaneously (yes, I know, you can do the profile dance, but most developers just don't want to and think it's a hassle)

- We need to be able to install apps - both regular and packaged ones - through a web page. Fabrice's initiative to push apps is commendable, but a) Most developers won't have a device, and b) It's the web, so running things from a web page and install directly is just the ease-of-development we should aim for

- We need to support as many APIs as possible. Those we can't/shouldn't, need to be stubbed


I think Myk's approach and the Firefox OS Simulator was fantastic, especially when it comes to making lives easier for developers. Yes, it might miss some things, and yes, the workflow could be simplified. But, it did something that we haven't even been close to before: getting developers excited and to try things out!

Before, the things needed to get started was too much, and developers just didn't do it. Now, all the time, I meet a lot of developers that thank me (us) for the Simulator and telling me just how easy it is.

Imagine building on top of that excitement, what we could accomplish!

From my point of view, we have two options:

- Build a separate Firefox that lives up to everything I mentioned in the first point above
- Build app and WebAPIs support into Firefox directly, and enabling it through a menu (preferably), flag or similar

No matter which option we choose, they need to:

- Be able to install regular and packaged/privileged apps
- Support WebAPIs, and stub those that aren't applicable
- Support remote debugging for devices
- The resolution and resources (fonts etc) should be in there, and it should look just as Gaia on a device

I'd also argue that devices need a developer setting, where you can turn on the possibility to install packages directly from its web browser.


On the point of WebAPIs and samples:

This was one of the main reasons I built the Firefox OS Boilerplate App (https://github.com/robnyman/Firefox-OS-Boilerplate-App).
To have working and running examples of WebAPI's usage and Web Activities.

In addition to that, I'm writing a blog post on WebAPIs for Mozilla Hacks that will be published today. It will be far from covering everything, but hopefully a good start (and depending on feedback etc, migrate that into MDN).


On the general topic of tools:

It seems that Myk with the Firefox OS Simulator, and Arnau who did http://buildingfirefoxos.com/ have gotten shit (not here, but elsewhere) from other people (discussions on user experience, code quality). Stop that. Right now.

They built excellent tools/services that by far surpassed what we've been able to offer developers before. They got developers excited, they packaged it great and the results when it comes to interest and people starting to hack are stunning!

They took initiative. That should be encouraged, and if you don't like their results, help them and contribute.



Best regards,
Robert Nyman

[Luigi Tedone]

Why can't we customize an IDE like Aptana? It would be also great to
have a tool like Sencha Architect or maquetta.org for quickly
prototyping the UI of applications (using building blocks)

[Julien Wajsberg]

Le 07/02/2013 00:12, davidw...@gmail.com a �crit :

> I've shared many of the same frustrations as some other developers
above. In creating the Quick Start Guide
(https://github.com/darkwing/firefoxos-quick-start) requested of me by
Dev Ecosystem team, I ran into the following issues:
>
>

> 2. API documentation is horribly lacking at the moment. The wiki
page (https://wiki.mozilla.org/WebAPI) isn't ideal because in most
cases it's nowhere near enough information to get started using said
APIs, and the MDN page (https://developer.mozilla.org/en-US/docs/WebAPI)
shows very little detail as well. It will be difficult to host a hack
day when users don't know how to use the tools we've provided to them.
We need to do a better job getting documentation completed; basic
explanations of APIs with lots of code samples.

We're contracting talented people to do this right now. I've heard that
this is planned to have everything quite ready in time for MWC.

>
> The thread started by addressing the dev stack issue, so a few ideas:
>
> 1. Being able to complete apps in Nightly would be ideal but I know
that would be almost impossible from a technical standpoint. The APIs
that can be exposed on desktop, however, should be.
>
> 2. I'm wondering if there's a tool we could create that could act
similar to how FirebugLite did. Include a JS file in your app and it
could act as a shortcut to re-install an app and do other similar
functionalities.

It's actually quite easy to make an app update itself. I published it
for a packaged app there :
https://github.com/julienw/self-updating-packaged-app and
hosted+appcache app works quite the same (except for the install part).

>
> 3. Remote debugging would be epic.

It's being worked on, if not already working (I've read yesterday on IRC
that it was working, so someone may have more information).

--
Julien

[Julien Wajsberg]

Le 07/02/2013 12:19, Luigi Tedone a �crit :

> Why can't we customize an IDE like Aptana? It would be also great to
> have a tool like Sencha Architect or maquetta.org for quickly
> prototyping the UI of applications (using building blocks)

With unlimited time and resources, we can do everything :-)

[David Bruant]

Le 07/02/2013 14:05, Julien Wajsberg a �crit :

> Le 07/02/2013 00:12, davidw...@gmail.com a �crit :
>

>> I've shared many of the same frustrations as some other developers
> above. In creating the Quick Start Guide
> (https://github.com/darkwing/firefoxos-quick-start) requested of me by
> Dev Ecosystem team, I ran into the following issues:

>> 2. API documentation is horribly lacking at the moment. The wiki
> page (https://wiki.mozilla.org/WebAPI) isn't ideal because in most
> cases it's nowhere near enough information to get started using said
> APIs, and the MDN page (https://developer.mozilla.org/en-US/docs/WebAPI)
> shows very little detail as well. It will be difficult to host a hack
> day when users don't know how to use the tools we've provided to them.
> We need to do a better job getting documentation completed; basic
> explanations of APIs with lots of code samples.
>

> We're contracting talented people to do this right now. I've heard that
> this is planned to have everything quite ready in time for MWC.

Indeed (about MWC). Since there is a lot to cover, the current strategy
is to get a page for each API for MWC (and add interesting code samples
and examples afterward). But writing good examples, testing them, etc.;
writing good documentation does take time.

WebAPI Documentation status can be found at
https://developer.mozilla.org/en-US/docs/WebAPI/Doc_status (colors,
courtesy of the *very* talented J�r�mie Patonnier).

If you're reading this message and wrote a Gaia app using one of the
APIs in green or yellow, please take a look at the page, review it, add
a small example highlighting the most important/interesting part of the
APIs. It may just be copy/pasting and cleaning up a bit the Gaia code;
since you know this code, you'll be able to do that faster than anyone else.

... back to documenting the WebFM API :-)

David

[robmca...@gmail.com]

We already have a fairly comprehensive developer tools suite built into Firefox Desktop. What we haven't heard is a lot of requests for features from Firefox OS and App builders. I expect that to change once the initial rush to ship 1.0 is over.

We're working hard to support Firefox OS so our Debugger, Console and eventually Inspector will work on the device itself or on the simulator.

We're discussing what it will take to adopt the FirefoxOS Simulator to make it a first-class feature in Firefox.

It's early days for Firefox OS and we're only just reaching the point with our built-in developer tools in Firefox where we can entertain the idea of having comprehensive developer tools for building apps. I think over this year, we'll get closer to having a full tool-suite that will help app developers through their whole workflow.

I also think that we need to do more to enable the WebAPIs in Firefox OS in desktop Firefox as Dietrich and others have suggested. Integrating those with our developer tools should be important.

Before we go off and start customizing another IDE to do what we need, I recommend working with us to make our own tools do the right thing. It won't be Xcode. It'll be Firefox!

File bugs, hang out in #devtools, talk to us.

~ robcee

[Panos Astithas]

On Thu, Feb 7, 2013 at 3:05 PM, Julien Wajsberg <jwaj...@mozilla.com>wrote:

> Le 07/02/2013 00:12, davidw...@gmail.com a écrit :

> 3. Remote debugging would be epic.
>

> It's being worked on, if not already working (I've read yesterday on IRC
> that it was working, so someone may have more information).
>

It is still working, as I verified yesterday. The problem seems to be that
there was a recent change in the default pref for Marionette, that might
have affected people who didn't explicitly disable it when enabling the
debugger.

Also, the remote profiling frontend (without the add-on) is already in
fx-team and will be in Nightlies in the next few days. Work is also
underway on remoting the rest of our developer tools and fixing bugs in the
existing ones, but it's a lot of work so it will take some time.

Panos

[Schalk Neethling]

Hey all,

Thanks Kevin for starting this thread. There is a lot of work still to
be done in this space and the more people talk about this and provide
their input, the better we can not only define what is missing but, put
together and implement an effective road map to make developing apps for
FirefoxOS go from sucks to rocks ;)

>> Fabrice Desr�

>>
>> b2g team
>>
>> Mozilla Corporation
>
> Fabrice,
> I was wrong to accuse the security model without being fully aware of the reasons as to why packaged app development sucks. But that's what I'm trying to find out. I know you personally put a lot of time and hard work into it. Security models are way over my head, and I overstepped in referring to it as something unusable.
>
> I'm not comfortable telling third party devs that we have an outdated tools that they are expected use to develop packaged apps. If people say FFOS sucks because they didn't get to use the device API's that we promised, then that will break my heart and I'm trying to prevent that.

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>

--

Kind Regards,
Schalk Neethling
Front-End Engineer
Mozilla

[Julien Wajsberg]

Le 07/02/2013 15:54, Panos Astithas a écrit :
> On Thu, Feb 7, 2013 at 3:05 PM, Julien Wajsberg <jwaj...@mozilla.com
> <mailto:jwaj...@mozilla.com>> wrote:
>
> Le 07/02/2013 00:12, davidw...@gmail.com

> <mailto:davidw...@gmail.com> a écrit :

>
> > 3. Remote debugging would be epic.
>

> It's being worked on, if not already working (I've read yesterday on IRC
> that it was working, so someone may have more information).
>
>
> It is still working, as I verified yesterday. The problem seems to be
> that there was a recent change in the default pref for Marionette, that
> might have affected people who didn't explicitly disable it when
> enabling the debugger.

IIRC what didn't work before was remote debugging out of process apps,
ie everything except system unless we disable OOP. Is it working now ?

--
Julien

[Myk Melez]

On 2013/02/06 11:12, Kevin Grandon wrote:
> Just for comparison: iOS developers use *the* XCode emulator. Android developers use *the* android emulator. FFOS devs use r2d2b2g, b2g desktop, or FF nightly.

Or the B2G emulators.

It's useful to consider what other OSes provide, but we should be
careful about the lessons we draw from them. Firefox OS isn't "just the
web," so the story isn't as simple as "the exact same tools you already
use." But it also isn't "just another mobile OS," and we are not
necessarily best served by simply adopting the strategy of our competitors.

> There's clearly a problem that we aren't focused on our developer offerings here. We don't have a single development experience which we offer as a product and is easily debugged. I think we can do a lot better, and in my mind we should be using the browser for all FFOS app development.

Six months ago, this is exactly what DevEngage recommended to developers
at events. And the feedback I heard from them (f.e. Havi, cc:ed) was
that we had difficulty gaining traction because Firefox Desktop doesn't
feel enough like a mobile device, despite Response Design View.

And the Simulator, after DevEngage began to incorporate it into their
pitches, made a huge difference, even in its nascent state, because it
does feel like a mobile device, like the embryonic Firefox OS.

Granted, that developer reaction is irrational. And it may change once
actual devices are generally available. But that doesn't make it any
less real
<http://www.amazon.com/Emotional-Design-Love-Everyday-Things/dp/0465051359>.
We need to consider what developers desire in addition to what they need.

> There are several possible ways to implement this, here is what I'm currently thinking:
>
> - Use a barebones Firefox install as our *only* supported emulator
> - Support all WebAPIs fully. (Can the dialer make a call with WebRTC?)
> - Support all system fonts, shared resources, building blocks.
> - Perhaps the developer could launch the app by drag/dropping the manifest on firefox, or navigating to it.
>
>
> There are stepping stones we could take to get to that point, but in my eyes that is the golden land. Please send your thoughts, and if there's interest, let's find a way to unify our developer offerings.

We can certainly make the Firefox experience better. But I'm not sure we
can make it as good as we can make the Simulator experience, once the
rest of Firefox's developer tools are made remoteable.

Besides feeling more like Firefox OS, the Simulator (and B2G) also has a
GRE compiled differently from Firefox's; and Fabrice has previously
suggested that the delta is both significant and difficult to narrow
(although it's certainly worth experimenting with doing so).

And then there are the web activities that Gaia core apps provide and
third-party apps will want to access, for which it is insufficient to
provide an environment that runs just the developer's app. We need to
provide all of Gaia (or at least all core apps that register activities)
to give developers the experience of using those activities.

-myk

[Myk Melez]

On 2013/02/06 11:48, Stefan Arentz wrote:
> The Firefox OS Simulator is good to try out your app when you don't have a phone. But that is it. To use it for development is not a great experience because it is so bare bones. My workflow has been:
>
> 10 edit index.html
> 20 switch to firefox, find the simulator tab, hit the Update button for my app
> 30 find the B2G app because it does not automatically come to the foreground
> 40 wait until B2G.app is ready 'booting'. Try out my app. browse through the console.

Your reference to B2G.app suggests you're on a Mac. And the Simulator
has Mac-specific code to raise B2G to the foreground after starting it.

That code was heuristic and unreliable in earlier versions, but it
should be reliable in newer ones. Try out the latest preview release (
Windows
<https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-windows.xpi>,
Mac
<https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-mac.xpi>,
Linux
<https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-linux.xpi>),
and let me know if you still see this problem.

> Ideally we have all the B2G APIs available in a special mode of Firefox. Then I would like to boot Firefox OS in a tab, set the responsive layout to phone size and use all the awesome tools we have available there. The Web Console, Scratchpad, Inspector, Profiler and Developer Toolbar.

By "boot Firefox OS" I assume you mean load Gaia (the operating
environment, which provides the user interface). According to Fabrice
(cc:ed), this is hard, because Gecko is built with a different
configuration for B2G (although I don't know the details), and Gaia
depends on that different configuration. Which is one of the reasons the
Simulator ships its own GRE.

Nevertheless, it's worth investigating the differences to determine the
feasibility of reducing them enough to load Gaia in Firefox.

> Also, I just want to hit Command-R to reload my app.

That's a great idea and one that we should be able to implement in any
environment, whether Firefox proper, the Simulator, or something else.

> I know I'm raising the bar :-)

Nothing wrong with that!

-myk

[Myk Melez]

On 2013/02/06 12:57, Vivien wrote:
> There is a team at Mozilla dedicated to making third party developer
> life easier but I'm not sure which mailing list they use.

The lists are dev.developer-tools
<http://www.mozilla.org/about/forums/#dev-developer-tools> and
engagement.developers
<http://www.mozilla.org/about/forums/#engagement-developers>.

-myk

[Myk Melez]

On 2013/02/06 15:12, davidw...@gmail.com wrote:
> I've shared many of the same frustrations as some other developers above. In creating the Quick Start Guide (https://github.com/darkwing/firefoxos-quick-start) requested of me by Dev Ecosystem team, I ran into the following issues:
>
> 1. The Simulator we promote (https://marketplace.firefox.com/developers/docs/firefox_os_simulator) is well, well outdated. API support isn't current and once I uninstall an app, I need to reinstall the Simulator plugin to reinstall because the app icon never displays on the home screen again. Myk sent me an updated simulator but that doesn't do the public any good. We should really be updating this simulator on a more frequent basis.

I agree, and we could do so if we only had more than a single part-time
engineer working on the project.

In the meantime, this part-time engineer has pushed a new stable release
of the Simulator (with B2G/Gaia 18/v1 code from 2013-01-18) to AMO,
where it is awaiting review; and updated B2G/Gaia to 2013-02-06 in the
Simulator's code repository, from which it'll make its way into the
first preview of the next release.

> 3. Remote debugging would be epic.

Remote debugging is already possible from Firefox nightly builds to the
latest preview release of the Simulator ( Windows

<https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-windows.xpi>,
Mac
<https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-mac.xpi>,
Linux

<https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-linux.xpi>).
To access it, press the Connect... button that appears underneath the
Simulator switch in the Dashboard when the Simulator is running.

-myk

[Julien Wajsberg]

Le 07/02/2013 17:25, Myk Melez a �crit :

> On 2013/02/06 15:12, davidw...@gmail.com wrote:

>> I've shared many of the same frustrations as some other developers
>> above. In creating the Quick Start Guide
>> (https://github.com/darkwing/firefoxos-quick-start) requested of me by
>> Dev Ecosystem team, I ran into the following issues:
>>
>> 1. The Simulator we promote
>> (https://marketplace.firefox.com/developers/docs/firefox_os_simulator)
>> is well, well outdated. API support isn't current and once I
>> uninstall an app, I need to reinstall the Simulator plugin to
>> reinstall because the app icon never displays on the home screen
>> again. Myk sent me an updated simulator but that doesn't do the
>> public any good. We should really be updating this simulator on a
>> more frequent basis.

> I agree, and we could do so if we only had more than a single part-time
> engineer working on the project.
>
> In the meantime, this part-time engineer has pushed a new stable release
> of the Simulator (with B2G/Gaia 18/v1 code from 2013-01-18) to AMO,
> where it is awaiting review; and updated B2G/Gaia to 2013-02-06 in the
> Simulator's code repository, from which it'll make its way into the
> first preview of the next release.
>

>> 3. Remote debugging would be epic.

> Remote debugging is already possible from Firefox nightly builds to the
> latest preview release of the Simulator ( Windows
> <https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-windows.xpi>,
> Mac
> <https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-mac.xpi>,
> Linux
> <https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-linux.xpi>).
> To access it, press the Connect... button that appears underneath the
> Simulator switch in the Dashboard when the Simulator is running.

These are more awesome news in a already awesome world.

Thanks Myk for your work :)

--
Julien

[robmca...@gmail.com]

On Thursday, 7 February 2013 06:19:40 UTC-5, Luigi Tedone wrote:

We already have a fairly comprehensive developer tools suite built into Firefox Desktop. What we haven't heard is a lot of requests for features from Firefox OS and App builders. I expect that to change once the initial rush to ship 1.0 is over.

We're working hard to support Firefox OS so our Debugger, Console and eventually Inspector will work on the device itself or on the simulator.

We're discussing what it will take to adopt the FirefoxOS Simulator to make it a first-class feature in Firefox.

It's early days for Firefox OS and we're only just reaching the point with our built-in developer tools in Firefox where we can entertain the idea of having comprehensive developer tools for building apps. I think over this year, we'll get closer to having a full tool-suite that will help app developers through their whole workflow.

I also think that we need to do more to enable the WebAPIs in Firefox OS in desktop Firefox as Dietrich and others have suggested. Integrating those with our developer tools should be important.

Before we go off and start customizing another IDE to do what we need, I recommend working with us to make our own tools do the right thing. It won't be Xcode. It'll be Firefox!

File bugs, hang out in #devtools, talk to us.

~ robcee

[robn...@gmail.com]

> Just for comparison: iOS developers use *the* XCode emulator. Android developers use *the* android emulator. FFOS devs use r2d2b2g, b2g desktop, or FF nightly.
>
>
>

> There's clearly a problem that we aren't focused on our developer offerings here. We don't have a single development experience which we offer as a product and is easily debugged. I think we can do a lot better, and in my mind we should be using the browser for all FFOS app development. There are several possible ways to implement this, here is what I'm currently thinking:

>
>
>
> - Use a barebones Firefox install as our *only* supported emulator
>
> - Support all WebAPIs fully. (Can the dialer make a call with WebRTC?)
>
> - Support all system fonts, shared resources, building blocks.
>
> - Perhaps the developer could launch the app by drag/dropping the manifest on firefox, or navigating to it.
>
>
>
>
>
> There are stepping stones we could take to get to that point, but in my eyes that is the golden land. Please send your thoughts, and if there's interest, let's find a way to unify our developer offerings.
>
>
>

> Thanks,
>
> Kevin

[Panos Astithas]

On Thu, Feb 7, 2013 at 5:37 PM, Julien Wajsberg <jwaj...@mozilla.com>wrote:

> Le 07/02/2013 15:54, Panos Astithas a écrit :
> > On Thu, Feb 7, 2013 at 3:05 PM, Julien Wajsberg <jwaj...@mozilla.com
> > <mailto:jwaj...@mozilla.com>> wrote:
> >
> > Le 07/02/2013 00:12, davidw...@gmail.com
> > <mailto:davidw...@gmail.com> a écrit :
> >

> > > 3. Remote debugging would be epic.
> >

> > It's being worked on, if not already working (I've read yesterday on
> IRC
> > that it was working, so someone may have more information).
> >
> >
> > It is still working, as I verified yesterday. The problem seems to be
> > that there was a recent change in the default pref for Marionette, that
> > might have affected people who didn't explicitly disable it when
> > enabling the debugger.
>
> IIRC what didn't work before was remote debugging out of process apps,
> ie everything except system unless we disable OOP. Is it working now ?

No, but bug 797627 is being actively worked on.

Panos

[Rob Campbell]

On Thursday, 7 February 2013 04:56:04 UTC-5, robn...@gmail.com wrote:
> Hi,
>
>
>
> Interesting to see this thread and the initiatives!
>
> My thoughts:
>
>
>
> - IF we do a separate version of Firefox it needs to have a separate profile by default, be able to run side-by-side with regular Firefox and more. For years, it seems like the solution has been to throw another version of Firefox into the mix, and then most developers just get sick of not being able to run multiple version simultaneously (yes, I know, you can do the profile dance, but most developers just don't want to and think it's a hassle)

We're not making a separate version of Firefox. Our developer tools are integrated.

~ rob

[Rob Campbell]

On Thursday, 7 February 2013 04:56:04 UTC-5, robn...@gmail.com wrote:

> Hi,
>
>
>
> Interesting to see this thread and the initiatives!
>
> My thoughts:
>
>
>
> - IF we do a separate version of Firefox it needs to have a separate profile by default, be able to run side-by-side with regular Firefox and more. For years, it seems like the solution has been to throw another version of Firefox into the mix, and then most developers just get sick of not being able to run multiple version simultaneously (yes, I know, you can do the profile dance, but most developers just don't want to and think it's a hassle)

[robn...@gmail.com]

> We're not making a separate version of Firefox. Our developer tools are integrated.

I understood it as if that was one of the options from reading this thread. Reading more closely it doesn't seem like that (and I wouldn't want that anyway).


Best regards,
Robert

[robn...@gmail.com]

> We're not making a separate version of Firefox. Our developer tools are integrated.

I understood it as if that was one of the options from reading this thread. Reading more closely it doesn't seem like that (and I wouldn't want that anyway).


Best regards,
Robert



On Thursday, 7 February 2013 23:16:33 UTC+1, Rob Campbell wrote:

[Myk Melez]

On 2013/02/07 01:56, robn...@gmail.com wrote:
> It seems that Myk with the Firefox OS Simulator, and Arnau who did http://buildingfirefoxos.com/ have gotten shit (not here, but elsewhere) from other people (discussions on user experience, code quality). Stop that. Right now.

Thanks for having my back! Behind which is apparently where people have
been giving me shit, since they haven't done it to my face, and this is
the first I've heard of it.

Nevertheless, although there's plenty of room to criticize the quality
of the Simulator, its current state is very much intentional, as it was
written to be a prototype, not a product (even though app developers are
now using it as one). And that's how it'll stay until additional Mozilla
engineers commit to developing it.

-myk

[Kevin Grandon]

Thanks for the awesome feedback guys. There certainly seems to be a lot of opinions on this topic, but I think we all agree that we can do much better. I've heard that this has come up in the past, so I'd really like to gather some action items this time and push forward.

I'm starting a spreadsheet which will allow us to input a desired set of "requirements" for the development experience, and compare those against our current solutions. I'm thinking that this might help us in creating action items and find owners/volunteers to take them on.

The spreadsheet can be found here, and anyone can contribute for now: https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AkOkN0YecwNjdFphZ3BkMmVRcGhndF9aX2V2ZTVXaGc#gid=0

I'm not a product manager by any means so if there's a better way of getting stuff done based on this conversation, please follow up with me offline and we can follow the proper procedures.

Thanks,
Kevin Grandon

[morgamic]

Hi everyone,

Few things:
- spreadsheet is great, I think this helps
- just found about this thread
- have a lot of thoughts on the topic and have been trying to grok what we're facing for the last few weeks
- there are quite a few folks thinking about the ecosystem

I'd like to share/discuss:
- a comprehensive report on what developers said about related topics that Mozilla sponsored [1]
- what work we have started (not done) so far to piece together the developer experience [2]
- how to organize a concerted effort to help web developers build for Firefox OS (and for the mobile-first web in general)

Everyone's been super busy, so some things to note:
- web developers at mozilla who build the marketplace and other web apps are also working on whatever we can do to help web developers build for Firefox OS
- there's a talented group of folks focused on building tools, libs, examples for Firefox OS app developers [3]
- we have had discussions with UX to figure out how to document current design elements for devs -- up to and probably including contributing to buildingfirefoxos.com

Current challenges:
- lack of clarity about tying together our tools (I think Kevin's spreadsheet helps with this) but we need more discussion on what our "SDK" looks like (or, a more unified set of tools)
- I don't think we have identified which developers need what the most; we should figure this out and do some research
- we have multiple channels where similar topics are being discussed, so it's confusing for everyone
- we DO have product folks to help plan some of this out, so I can help connect the dots there
- the whole ecosystem is a pretty huge thing to tackle in general

Suggestions/ideas:
- Kevin - might be worth pinging Bill Walker, Myk and Dave Camp about your spreadsheet and see how it lines up with current efforts
- Kevin - I'd like to speak with you about how I can help/contribute, and what we've been building/thinking so far for other parts of the developer flow/experience
- All - the github "flow" I have isn't complete (it's an experiment) but it's based on ecosystem components needed by most developers, starting at a high level. I'd like feedback on whether or not this type of tracking would be helpful; kind of like a "areweeasyyet.com" or something. I'll continue to update it tomorrow.

I'm glad this discussion is happening -- there's a lot to figure out. Let's make it all better.

Mike

1 - http://www.visionmobile.com/product/developer-economics-2013-the-tools-report/
2 - http://morgamic.github.com/developer-flow/
3 - https://wiki.mozilla.org/Apps/Ecosystem

[morgamic]

[morgamic]

There's also dev.webapps
https://groups.google.com/forum/?fromgroups=#!forum/mozilla.dev.webapps

[morgamic]

On Thursday, February 7, 2013 8:24:02 AM UTC-8, Myk Melez wrote: