Native UI on Android
454 views
Skip to first unread message
Johnathan Nightingale
Oct 14, 2011, 5:28:45 PM10/14/11
to
[Cross-posted to dev.planning, followups to dev.platforms.mobile please]
Hey folks,
After substantial discussion, we have decided to build future versions
of Firefox on Android with a native UI instead of the current XUL
implementation. The team is already working on this project on the birch
branch [1], and we are tracking the early work on the wiki. [2] To be
clear, we're still building on Gecko. This change is just about the way
we build our UI.
There are several reasons for making this change, most notably:
* Startup - A native UI can be presented much faster than a XUL based
UI, since it can happen in parallel with Gecko startup. This means
startup times in fractions of a second, versus several seconds for a XUL
UI on some phones.
* Memory use - We believe a native UI will use significantly less memory
* Responsiveness - A native UI has the potential for beautiful panning
and zooming performance
Firefox on Android is a critical part of supporting the open web, and
this decision puts us in a position to build the best Firefox possible.
It's still early days, so we have a lot of questions to answer. We’re
talking with the Add-on SDK team about the best way to support
extensions. We’re talking with l10n about how to ensure we support
Firefox users wherever they live around the world.
Next week, the team is meeting in Toronto to break down this work and
prioritize it. We'll be on IRC in #mobile if you want to get involved,
and pushing updates to the repo regularly. By the end of next week, we
will have a clearer outline of the work ahead, and we'll update this
list with those details.
It's too early for us to determine when this work will be ready for
users, but we are certain that it will not impact the versions currently
on the Beta and Aurora channels. Firefox 8 and 9 will ship with the XUL
UI, including the new UI for tablets, while we build the native UI.
J
[1] http://hg.mozilla.org/projects/birch/
[2] https://wiki.mozilla.org/Fennec/NativeUI
--
Johnathan Nightingale
Director of Firefox Engineering
Hey folks,
After substantial discussion, we have decided to build future versions
of Firefox on Android with a native UI instead of the current XUL
implementation. The team is already working on this project on the birch
branch [1], and we are tracking the early work on the wiki. [2] To be
clear, we're still building on Gecko. This change is just about the way
we build our UI.
There are several reasons for making this change, most notably:
* Startup - A native UI can be presented much faster than a XUL based
UI, since it can happen in parallel with Gecko startup. This means
startup times in fractions of a second, versus several seconds for a XUL
UI on some phones.
* Memory use - We believe a native UI will use significantly less memory
* Responsiveness - A native UI has the potential for beautiful panning
and zooming performance
Firefox on Android is a critical part of supporting the open web, and
this decision puts us in a position to build the best Firefox possible.
It's still early days, so we have a lot of questions to answer. We’re
talking with the Add-on SDK team about the best way to support
extensions. We’re talking with l10n about how to ensure we support
Firefox users wherever they live around the world.
Next week, the team is meeting in Toronto to break down this work and
prioritize it. We'll be on IRC in #mobile if you want to get involved,
and pushing updates to the repo regularly. By the end of next week, we
will have a clearer outline of the work ahead, and we'll update this
list with those details.
It's too early for us to determine when this work will be ready for
users, but we are certain that it will not impact the versions currently
on the Beta and Aurora channels. Firefox 8 and 9 will ship with the XUL
UI, including the new UI for tablets, while we build the native UI.
J
[1] http://hg.mozilla.org/projects/birch/
[2] https://wiki.mozilla.org/Fennec/NativeUI
--
Johnathan Nightingale
Director of Firefox Engineering
Gervase Markham
Oct 15, 2011, 6:40:17 AM10/15/11
to
On 15/10/11 03:28, Johnathan Nightingale wrote:
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation.
At the All Hands, it was suggested that we only needed to do the main UI
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation.
natively, as that's the bit which has to come up fast. We could carry on
having all the secondary UI (e.g. addons screen, options etc.) in XUL,
which would lessen the work of porting add-ons and keep people in
familiar territory for as long as possible.
As I read it, all of the native UI benefits you list would be realised
by doing this.
What is the current plan in that regard?
Gerv
Robert Kaiser
Oct 15, 2011, 9:01:31 AM10/15/11
to
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation.
Does that stand true for phones only or for tablets as well?
> of Firefox on Android with a native UI instead of the current XUL
> implementation.
I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
things the Mozilla way at all, but I understand that the thinking seems
to be that Android phones don't deserve to have all the power we can
deliver, and I'm seriously hoping B2G will be a crushing success as then
this native UI thing will worry me less. That said, I hope at least
tablets, which already have a quite good experience with the current UI,
will stay with full Mozilla power.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
Asa Dotzler
Oct 16, 2011, 12:52:53 PM10/16/11
to
Robert Kaiser wrote:
> I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
> things the Mozilla way at all
When the Communicator 5 source code was released, and the Mozilla
> I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
> things the Mozilla way at all
project started, we had three native front ends and three distinct front
end teams. Resources were likely too limited to maintain those front
ends and there was the possibility that everything but Windows would be
dropped.
XUL and XPFE was able to moot that possibility and let us build a great
browser across many platforms, but it was not because XUL was the
"Mozilla way" it was because the Mozilla way was flexibility and
ingenuity in the face of existential challenges.
- A
Robert Kaiser
Oct 16, 2011, 5:22:58 PM10/16/11
to
Asa Dotzler schrieb:
those, because they didn't support the kind of flexible and powerful
add-on technology that we can only support because our UI is "webby".
> XUL and XPFE was able to moot that possibility and let us build a great
> browser across many platforms, but it was not because XUL was the
> "Mozilla way" it was because the Mozilla way was flexibility and
> ingenuity in the face of existential challenges.
There was no Mozilla the way we define it now back then. What is the
"Mozilla way" now only evolved over time - and without having Gecko
render the UI, the project would have died with Netscape, as it wouldn't
have been any more interesting or innovative technology than IE - and I
strongly believe that a Firefox with native Android UI won't be very
much better than the native Android browser.
Thankfully, there's still B2G, which takes a completely different route
and one I really feel at home with. ;-)
> Robert Kaiser wrote:
>> I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
>> things the Mozilla way at all
>
> When the Communicator 5 source code was released, and the Mozilla
> project started, we had three native front ends and three distinct front
> end teams.
And I'm pretty sure Firefox would not have been a smashing success using
>> I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
>> things the Mozilla way at all
>
> When the Communicator 5 source code was released, and the Mozilla
> project started, we had three native front ends and three distinct front
> end teams.
those, because they didn't support the kind of flexible and powerful
add-on technology that we can only support because our UI is "webby".
> XUL and XPFE was able to moot that possibility and let us build a great
> browser across many platforms, but it was not because XUL was the
> "Mozilla way" it was because the Mozilla way was flexibility and
> ingenuity in the face of existential challenges.
"Mozilla way" now only evolved over time - and without having Gecko
render the UI, the project would have died with Netscape, as it wouldn't
have been any more interesting or innovative technology than IE - and I
strongly believe that a Firefox with native Android UI won't be very
much better than the native Android browser.
Thankfully, there's still B2G, which takes a completely different route
and one I really feel at home with. ;-)
Asa Dotzler
Oct 16, 2011, 5:40:19 PM10/16/11
to
Robert Kaiser wrote:
> Asa Dotzler schrieb:
>> Robert Kaiser wrote:
>>> I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
>>> things the Mozilla way at all
>>
>> When the Communicator 5 source code was released, and the Mozilla
>> project started, we had three native front ends and three distinct front
>> end teams.
>
> And I'm pretty sure Firefox would not have been a smashing success using
> those, because they didn't support the kind of flexible and powerful
> add-on technology that we can only support because our UI is "webby".
>
>> XUL and XPFE was able to moot that possibility and let us build a great
>> browser across many platforms, but it was not because XUL was the
>> "Mozilla way" it was because the Mozilla way was flexibility and
>> ingenuity in the face of existential challenges.
>
> There was no Mozilla the way we define it now back then. What is the
> "Mozilla way" now only evolved over time - and without having Gecko
> render the UI, the project would have died with Netscape, as it wouldn't
> have been any more interesting or innovative technology than IE - and I
> strongly believe that a Firefox with native Android UI won't be very
> much better than the native Android browser.
>
> Thankfully, there's still B2G, which takes a completely different route
> and one I really feel at home with. ;-)
Where's that Kairo enthusiasm I know and love?! :D We make great
> Asa Dotzler schrieb:
>> Robert Kaiser wrote:
>>> I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
>>> things the Mozilla way at all
>>
>> When the Communicator 5 source code was released, and the Mozilla
>> project started, we had three native front ends and three distinct front
>> end teams.
>
> And I'm pretty sure Firefox would not have been a smashing success using
> those, because they didn't support the kind of flexible and powerful
> add-on technology that we can only support because our UI is "webby".
>
>> XUL and XPFE was able to moot that possibility and let us build a great
>> browser across many platforms, but it was not because XUL was the
>> "Mozilla way" it was because the Mozilla way was flexibility and
>> ingenuity in the face of existential challenges.
>
> There was no Mozilla the way we define it now back then. What is the
> "Mozilla way" now only evolved over time - and without having Gecko
> render the UI, the project would have died with Netscape, as it wouldn't
> have been any more interesting or innovative technology than IE - and I
> strongly believe that a Firefox with native Android UI won't be very
> much better than the native Android browser.
>
> Thankfully, there's still B2G, which takes a completely different route
> and one I really feel at home with. ;-)
products. We're not bound by any technology. We bend the technology to
our will to make users happy. If we need to, we'll make add-ons work
with a native UI. There are not technology barriers there we can't
overcome. Cowboy up, Kairo! We got big hills to climb :D
- A
Fabrice Desré
Oct 17, 2011, 1:06:12 AM10/17/11
to
On Sat, 15 Oct 2011 16:40:17 +0600, Gervase Markham wrote:
> At the All Hands, it was suggested that we only needed to do the main UI
> natively, as that's the bit which has to come up fast. We could carry on
> having all the secondary UI (e.g. addons screen, options etc.) in XUL,
> which would lessen the work of porting add-ons and keep people in
> familiar territory for as long as possible.
It's very likely that we'll have some in-content UI like a mobile
> At the All Hands, it was suggested that we only needed to do the main UI
> natively, as that's the bit which has to come up fast. We could carry on
> having all the secondary UI (e.g. addons screen, options etc.) in XUL,
> which would lessen the work of porting add-ons and keep people in
> familiar territory for as long as possible.
friendly version of about:addons. For preferences, downloads, etc. we'll
need some input from the UX guys.
> As I read it, all of the native UI benefits you list would be realised
> by doing this.
>
> What is the current plan in that regard?
wiki.mozilla.org/Fennec/NativeUI/addons . Inputs welcome!
Fabrice
flod
Oct 17, 2011, 2:59:11 AM10/17/11
to dev-platfo...@lists.mozilla.org
Honestly I'm scared by your plan: you've already decided to build a
native UI but, as far as I understand, you have no idea of the problems
you'll have on the l10n side. If you realize that localization will be
greatly limited by a native UI, will you change your decision?
Example: https://wiki.mozilla.org/Fennec/NativeUI/Architecture_Overview
> Localization of the native UI can work very similar to how we localize
> Java UI parts now.
Does it refer to this file?
http://hg.mozilla.org/mozilla-central/file/tip/embedding/android/locales/en-US/android_strings.dtd
If the answer is yes, what about this?
https://bugzilla.mozilla.org/show_bug.cgi?id=622429
Francesco
native UI but, as far as I understand, you have no idea of the problems
you'll have on the l10n side. If you realize that localization will be
greatly limited by a native UI, will you change your decision?
Example: https://wiki.mozilla.org/Fennec/NativeUI/Architecture_Overview
> Localization of the native UI can work very similar to how we localize
> Java UI parts now.
Does it refer to this file?
http://hg.mozilla.org/mozilla-central/file/tip/embedding/android/locales/en-US/android_strings.dtd
If the answer is yes, what about this?
https://bugzilla.mozilla.org/show_bug.cgi?id=622429
Francesco
Makoto Kato
Oct 17, 2011, 3:19:37 AM10/17/11
to
How about Fennec for Windows as an emulator of Fennec? Although we
still build it automatically, does we continue to maintain it for mobile
XUL UI?
still build it automatically, does we continue to maintain it for mobile
XUL UI?
Robert Kaiser
Oct 17, 2011, 6:42:27 AM10/17/11
to
Asa Dotzler schrieb:
I'm not for a native Android UI, though. I don't have to be for every
single thing we're doing. I sincerely hope that the tablet UI we have
now, which rocks (at least when using Personas), will stay alive and
will not be replaced with some (gah) Java-like gunk.
> Where's that Kairo enthusiasm I know and love?! :D
It's there, and I'm fully enthusiastic for B2G when it comes to mobile.
I'm not for a native Android UI, though. I don't have to be for every
single thing we're doing. I sincerely hope that the tablet UI we have
now, which rocks (at least when using Personas), will stay alive and
will not be replaced with some (gah) Java-like gunk.
Doug Turner
Oct 17, 2011, 8:00:50 AM10/17/11
to flod, dev-platfo...@lists.mozilla.org
Hi Francesco,
On Friday at 10am Toronto time, we will have a meeting to discuss l10n concerns.
We can use the following dialing info:
• US/International: +1 650 903 0800 x92 Conf# 209
• US toll free: +1 800 707 2533 (pin 369) Conf# 209
• Canada: +1 416 848 3114 x92 Conf# 209
If you can not make it, please send me your concerns -or- add them to the wiki:
https://intranet.mozilla.org/index.php?title=Mobile/WorkWeek_Oct_2011/L10N
Doug
> _______________________________________________
> dev-platforms-mobile mailing list
> dev-platfo...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platforms-mobile
On Friday at 10am Toronto time, we will have a meeting to discuss l10n concerns.
We can use the following dialing info:
• US/International: +1 650 903 0800 x92 Conf# 209
• US toll free: +1 800 707 2533 (pin 369) Conf# 209
• Canada: +1 416 848 3114 x92 Conf# 209
If you can not make it, please send me your concerns -or- add them to the wiki:
https://intranet.mozilla.org/index.php?title=Mobile/WorkWeek_Oct_2011/L10N
Doug
> dev-platforms-mobile mailing list
> dev-platfo...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platforms-mobile
Axel Hecht
Oct 17, 2011, 10:01:44 AM10/17/11
to
as you can't see the current concerns page, here's what's currently on it:
available locale codes?
how to ship localizations?
l20n mobile first?
locale selection in java/in gecko
testing for contributors
devices
emulators? (Pike never got one to run on mac)
If you have more, add them here or in email, please.
And yes, I don't think that the native android stuff is a step forward
l10n-infra-wise. I'll need to get a hello-world to come up to see what
native android is really doing UI wise, and see what options we have to
work in a good way at the side.
Axel
flod
Oct 17, 2011, 11:23:54 AM10/17/11
to dev-platfo...@lists.mozilla.org
Hi Doug,
I can't access the wiki with my LDAP account and unfortunately I'll be at
work on Friday (4PM). Possible concerns:
- Don't break existing tools and formats (see bug 622429 above, and
understand if this is still a issue).
- Do we have the same kind of flexibility we currently have with XUL? For
example widths that can be set for each locale in .dtd files.
- How do you plan to test this? I'm worried, in particular considering
the new release cycle.
Francesco
I can't access the wiki with my LDAP account and unfortunately I'll be at
work on Friday (4PM). Possible concerns:
- Don't break existing tools and formats (see bug 622429 above, and
understand if this is still a issue).
- Do we have the same kind of flexibility we currently have with XUL? For
example widths that can be set for each locale in .dtd files.
- How do you plan to test this? I'm worried, in particular considering
the new release cycle.
Francesco
Axel Hecht
Oct 17, 2011, 11:45:23 AM10/17/11
to
On 17.10.11 17:23, flod wrote:
> Hi Doug,
> I can't access the wiki with my LDAP account and unfortunately I'll be at
> work on Friday (4PM). Possible concerns:
>
> - Don't break existing tools and formats (see bug 622429 above, and
> understand if this is still a issue).
The funky way of quoting is gonna stay around for android-native l10n,
> Hi Doug,
> I can't access the wiki with my LDAP account and unfortunately I'll be at
> work on Friday (4PM). Possible concerns:
>
> - Don't break existing tools and formats (see bug 622429 above, and
> understand if this is still a issue).
yeah. I'm crossing my fingers that we may get around using that.
Which will break all our tooling, but in a good way :-)
> - Do we have the same kind of flexibility we currently have with XUL? For
> example widths that can be set for each locale in .dtd files.
> - How do you plan to test this? I'm worried, in particular considering
> the new release cycle.
Axel
flod
Oct 17, 2011, 11:39:55 AM10/17/11
to
Accessing this list via e-mail wasn't a smart idea, I received only
Doug's answer :-\ Trying now with Google Groups.
The list you wrote (is it in the wiki page Doug mentioned?) seems
already quite comprehensive, please publish Meeting Notes somewhere
(planet would be great) ;-)
Francesco
Doug's answer :-\ Trying now with Google Groups.
The list you wrote (is it in the wiki page Doug mentioned?) seems
already quite comprehensive, please publish Meeting Notes somewhere
(planet would be great) ;-)
Francesco
Shmerl
Oct 17, 2011, 12:29:35 PM10/17/11
to
On Oct 14, 5:28 pm, Johnathan Nightingale <john...@mozilla.com> wrote:
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation.
How will this work out for mobile Firefox on other platforms? For
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation.
example Meego, upcoming Tizen and new emerging free distributions
based on the Mer core (like Mer + Plasma Active)? They are normative
Linux, not Android. Does it mean you plan now to write a native UI for
every single case? Or Mozilla is dropping a powerful cross platform
appeal and putting Android as the only worthy candidate?
Regards,
Hillel.
Doug Turner
Oct 17, 2011, 3:26:14 PM10/17/11
to flod, dev-platfo...@lists.mozilla.org
I added those to the agenda.
On Oct 17, 2011, at 11:23 AM, flod wrote:
> Hi Doug,
> I can't access the wiki with my LDAP account and unfortunately I'll be at
> work on Friday (4PM). Possible concerns:
>
> - Don't break existing tools and formats (see bug 622429 above, and
> understand if this is still a issue).
On Oct 17, 2011, at 11:23 AM, flod wrote:
> Hi Doug,
> I can't access the wiki with my LDAP account and unfortunately I'll be at
> work on Friday (4PM). Possible concerns:
>
> - Don't break existing tools and formats (see bug 622429 above, and
> understand if this is still a issue).
> - Do we have the same kind of flexibility we currently have with XUL? For
> example widths that can be set for each locale in .dtd files.
> example widths that can be set for each locale in .dtd files.
> - How do you plan to test this? I'm worried, in particular considering
> the new release cycle.
>
> the new release cycle.
>
smaug
Oct 19, 2011, 6:48:23 AM10/19/11
to Johnathan Nightingale
I was told that the setup would have a thread running Java UI and a
thread running Gecko (web content).
So we'd give up all the good things multiple content process could give
us in the future (I know, Fennec has just one content process atm).
If one tab/domain does some animation, and some other tab does some
heave js too, the animation won't be smooth.
Also, if gecko crashes, the whole browser crashes.
There seems to be some perf problems integrating Flash to mobile-E10s.
But is that because of puppet widgets? Could content process Gecko paint
straight to the OS level?
I'm worried that if there will never be more than one process,
which has just one thread for Gecko's DOM operations, we can't utilize
multicore cpus well enough in the near future.
-Olli
thread running Gecko (web content).
So we'd give up all the good things multiple content process could give
us in the future (I know, Fennec has just one content process atm).
If one tab/domain does some animation, and some other tab does some
heave js too, the animation won't be smooth.
Also, if gecko crashes, the whole browser crashes.
There seems to be some perf problems integrating Flash to mobile-E10s.
But is that because of puppet widgets? Could content process Gecko paint
straight to the OS level?
I'm worried that if there will never be more than one process,
which has just one thread for Gecko's DOM operations, we can't utilize
multicore cpus well enough in the near future.
-Olli
jed
Oct 24, 2011, 1:03:13 PM10/24/11
to
T'would be great if this post could be addressed by Mozilla reps
charged w/this new direction?
Thank-you.
Brad Lassey
Oct 24, 2011, 2:24:21 PM10/24/11
to dev-platfo...@lists.mozilla.org
The e10s issue involving flash has to do with the fact that the android extensions to the NPAPI gives the plugin direct access to the jvm, which only exists in the chrome process. We actually implemented a cross process jni interface, only to find out that there are certain things that Flash expects to run on the main java thread, which is impossible to do from the content process.
-Brad
-Brad
flod
Oct 26, 2011, 3:42:14 AM10/26/11
to
Any news from last Friday meeting?
Francesco
Francesco
Gervase Markham
Oct 27, 2011, 6:32:30 AM10/27/11
to
On 14/10/11 22:28, Johnathan Nightingale wrote:
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation. The team is already working on this project on the birch
> branch [1], and we are tracking the early work on the wiki. [2] To be
> clear, we're still building on Gecko. This change is just about the way
> we build our UI.
This thread led to a lot of community questions, but not very many
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation. The team is already working on this project on the birch
> branch [1], and we are tracking the early work on the wiki. [2] To be
> clear, we're still building on Gecko. This change is just about the way
> we build our UI.
answers. Is there any possibility of the team engaging with some of them?
In particular, I would like to ask:
- Is the XUL UI going to be abandoned, or are we developing the two in
parallel? Arguments against abandoning it include all the same
cross-platform ones against abandoning XUL on the desktop, plus also
that presumably we need a XUL-based browser UI for B2G.
- Do we plan to do this just for phones, or also for tablets (which have
more horsepower, more memory and perhaps a touch less need for immediacy)?
- Do we plan to reimplement all UI natively, or just the
performance-critical main window?
Gerv
Mark Finkle
Oct 27, 2011, 11:44:03 AM10/27/11
to Gervase Markham
On 10/27/2011 06:32 AM, Gervase Markham wrote:
> This thread led to a lot of community questions, but not very many
> answers. Is there any possibility of the team engaging with some of them?
Here is some current information, subject to change of course.
> This thread led to a lot of community questions, but not very many
> answers. Is there any possibility of the team engaging with some of them?
> In particular, I would like to ask:
>
> - Is the XUL UI going to be abandoned, or are we developing the two in
> parallel? Arguments against abandoning it include all the same
> cross-platform ones against abandoning XUL on the desktop, plus also
> that presumably we need a XUL-based browser UI for B2G.
for Maemo/Meego and is still actively being maintained by Mozilla[1] and
contributors. We plan to add the Native UI code to mozilla-central in a
way that does not obsolete the XUL UI code.
> - Do we plan to do this just for phones, or also for tablets (which have
> more horsepower, more memory and perhaps a touch less need for immediacy)?
and tablets. The XUL UI will likely be used on Fx11 and perhaps Fx12
releases on tablets - until the Native UI implements full tablet support
as well. Release roadmaps are hard to predict and can change, but this
gives you a general idea.
> - Do we plan to reimplement all UI natively, or just the
> performance-critical main window?
# We plan on supporting add-ons using the Native UI as well. XUL UI
overlays won't be possible, but restartless add-ons will be supported. A
NativeWindow API, which allows add-ons to interop with parts of the
native chrome UI, has started forming in the nightly builds.
----
[1] - since Mozilla is shipping the XUL UI for some "in the pipeline"
releases.
Axel Hecht
Oct 27, 2011, 11:47:51 AM10/27/11
to
On 26.10.11 09:42, flod wrote:
> Any news from last Friday meeting?
>
> Francesco
Things are going to be in-flux and interesting, in particular for l10n.
> Any news from last Friday meeting?
>
> Francesco
Right now, folks are working on the birch project repo, and use
embedding/android/locales/en-US/android_strings.dtd for their UI strings.
That's at least the back-up plan, I'm currently diving into what android
really does to check our options. I'm scribbling down my findings on
https://wiki.mozilla.org/L10n:Native_Android.
Which repos, when, etc are all in TBD, we're meeting on a weekly basis
for now.
Axel
Shmerl
Oct 27, 2011, 9:31:09 PM10/27/11
to
On Oct 27, 11:44 am, Mark Finkle <mark.fin...@gmail.com> wrote:
> The XUL UI will live on in the Mozilla source repo. The XUL UI is used
> for Maemo/Meego and is still actively being maintained by Mozilla[1] and
> contributors. We plan to add the Native UI code to mozilla-central in a
> way that does not obsolete the XUL UI code.
Do you consider at some point supporting a full blown Qt port, which
> The XUL UI will live on in the Mozilla source repo. The XUL UI is used
> for Maemo/Meego and is still actively being maintained by Mozilla[1] and
> contributors. We plan to add the Native UI code to mozilla-central in a
> way that does not obsolete the XUL UI code.
could optimize Maemo/Meego and future Tizen/Nemo Firefox ports? It
falls in line with your move towards native UI for optimization
purposes. Qt port can also benefit desktop KDE users.
Thanks,
Hillel.
Robert Kaiser
Oct 28, 2011, 8:37:23 AM10/28/11
to
Shmerl schrieb:
dedicated to the Open Web and using "webby" technology to build our UI
is the anchor point of the success of our Add-ons system. Without it,
that's gone. If it's giving in to a system that was built to make
everything non-Dalvik to suck and recognize that Google has won on
Android or if it's throwing everything away for Qt does not matter. Both
are equally not reflecting what Mozilla stands for - innovation and the
Open Web.
The native Android UI is only done because that system sucks so much for
doing things without a "native" UI that it looks like we can't avoid it
for low-perf devices that have a really big share of the market. I'm
pretty sure we only would think about doing the same with Qt if Qt-based
devices would rule the market equally as Android and iOS do on the
smartphone market right now and at the same time those Qt-based devices
would equally suck on running the "webby" UI that actually reflects what
Mozilla stands for.
> Do you consider at some point supporting a full blown Qt port
Full Qt is just as bad for Mozilla as full native Android UI is. We are
dedicated to the Open Web and using "webby" technology to build our UI
is the anchor point of the success of our Add-ons system. Without it,
that's gone. If it's giving in to a system that was built to make
everything non-Dalvik to suck and recognize that Google has won on
Android or if it's throwing everything away for Qt does not matter. Both
are equally not reflecting what Mozilla stands for - innovation and the
Open Web.
The native Android UI is only done because that system sucks so much for
doing things without a "native" UI that it looks like we can't avoid it
for low-perf devices that have a really big share of the market. I'm
pretty sure we only would think about doing the same with Qt if Qt-based
devices would rule the market equally as Android and iOS do on the
smartphone market right now and at the same time those Qt-based devices
would equally suck on running the "webby" UI that actually reflects what
Mozilla stands for.
Asa Dotzler
Oct 28, 2011, 11:59:18 AM10/28/11
to
Robert Kaiser wrote:
> Shmerl schrieb:
>> Do you consider at some point supporting a full blown Qt port
>
> Full Qt is just as bad for Mozilla as full native Android UI is. We are
> dedicated to the Open Web and using "webby" technology to build our UI
> is the anchor point of the success of our Add-ons system. Without it,
> that's gone.
You don't have to have XUL to have "webby" add-ons. I've been poking
> Shmerl schrieb:
>> Do you consider at some point supporting a full blown Qt port
>
> Full Qt is just as bad for Mozilla as full native Android UI is. We are
> dedicated to the Open Web and using "webby" technology to build our UI
> is the anchor point of the success of our Add-ons system. Without it,
> that's gone.
around in Chrome add-ons and they're more "webby" than XUL add-ons.
They're the genuine Web, not simply "webby" -- and Chrome has native
front ends.
- A
Gervase Markham
Oct 28, 2011, 12:12:49 PM10/28/11
to
On 27/10/11 16:44, Mark Finkle wrote:
> Here is some current information, subject to change of course.
Thanks - this is very informative.
> Here is some current information, subject to change of course.
>> - Is the XUL UI going to be abandoned, or are we developing the two in
>> parallel? Arguments against abandoning it include all the same
>> cross-platform ones against abandoning XUL on the desktop, plus also
>> that presumably we need a XUL-based browser UI for B2G.
>
> # The XUL UI will live on in the Mozilla source repo. The XUL UI is used
> for Maemo/Meego and is still actively being maintained by Mozilla[1] and
> contributors. We plan to add the Native UI code to mozilla-central in a
> way that does not obsolete the XUL UI code.
phones and tablets, Mozilla plans to officially maintain the XUL UI
alongside?
>> - Do we plan to reimplement all UI natively, or just the
>> performance-critical main window?
>
> # We plan on implementing all chrome UI using native widgets.
It seems to me that the motivations for native UI apply far more
strongly to the main window than the rest of the UI. That's the bit that
needs to appear quickly on startup, and which deals with scrolling.
If we keep the rest of the UI in XUL, we would have far fewer problems
with the effort of maintaining two UIs, and with addons which wanted to
support both desktop and mobile having to deal with two UIs.
I realise there are plans to support addons using new APIs, but why
create new APIs if we can just keep the old ones?
Of course, it's not a free lunch, but I'd be interested to understand
why this option was discarded.
Gerv
Robert Kaiser
Oct 28, 2011, 12:17:37 PM10/28/11
to
Asa Dotzler schrieb:
CSS? as _that_ is "webby". Most JS - even on the web - isn't.
> You don't have to have XUL to have "webby" add-ons. I've been poking
> around in Chrome add-ons and they're more "webby" than XUL add-ons.
So most of their add-ons are implemented using a markup language and
> around in Chrome add-ons and they're more "webby" than XUL add-ons.
CSS? as _that_ is "webby". Most JS - even on the web - isn't.
Matt Brubeck
Oct 28, 2011, 12:35:07 PM10/28/11
to Robert Kaiser
On 10/28/2011 09:17 AM, Robert Kaiser wrote:
> Asa Dotzler schrieb:
>> You don't have to have XUL to have "webby" add-ons. I've been poking
>> around in Chrome add-ons and they're more "webby" than XUL add-ons.
>
> So most of their add-ons are implemented using a markup language and
> CSS? as _that_ is "webby". Most JS - even on the web - isn't.
Yes, and the markup language is HTML. See the documentation for some
> Asa Dotzler schrieb:
>> You don't have to have XUL to have "webby" add-ons. I've been poking
>> around in Chrome add-ons and they're more "webby" than XUL add-ons.
>
> So most of their add-ons are implemented using a markup language and
> CSS? as _that_ is "webby". Most JS - even on the web - isn't.
examples:
http://code.google.com/chrome/extensions/getstarted.html
Fabrice Desré
Oct 28, 2011, 12:40:57 PM10/28/11
to
Robert,
On Fri, 28 Oct 2011 18:17:37 +0200, Robert Kaiser wrote:
> Asa Dotzler schrieb:
>> You don't have to have XUL to have "webby" add-ons. I've been poking
>> around in Chrome add-ons and they're more "webby" than XUL add-ons.
>
> So most of their add-ons are implemented using a markup language and
> CSS? as _that_ is "webby". Most JS - even on the web - isn't.
Honestly I don't see much value in arguing what is really "webby" and
what is not in this context. I care *very much* about add-ons on Fennec,
and we're doing what is needed to allow authors to write add-ons here.
Today there are few add-ons for fennec/xul, and most of them don't use
many overlays because the UI doesn't have a lot of useful places to
extend sanely. This means that we can offer the same functionality with
APIs instead of letting addon authors break the UI ;)
I'd be intersted in having you contribute, for instance here: https://
wiki.mozilla.org/Fennec/NativeUI/addons
Fabrice
On Fri, 28 Oct 2011 18:17:37 +0200, Robert Kaiser wrote:
> Asa Dotzler schrieb:
>> You don't have to have XUL to have "webby" add-ons. I've been poking
>> around in Chrome add-ons and they're more "webby" than XUL add-ons.
>
> So most of their add-ons are implemented using a markup language and
> CSS? as _that_ is "webby". Most JS - even on the web - isn't.
what is not in this context. I care *very much* about add-ons on Fennec,
and we're doing what is needed to allow authors to write add-ons here.
Today there are few add-ons for fennec/xul, and most of them don't use
many overlays because the UI doesn't have a lot of useful places to
extend sanely. This means that we can offer the same functionality with
APIs instead of letting addon authors break the UI ;)
I'd be intersted in having you contribute, for instance here: https://
wiki.mozilla.org/Fennec/NativeUI/addons
Fabrice
Robert Kaiser
Oct 28, 2011, 12:41:39 PM10/28/11
to
Matt Brubeck schrieb:
Interesting. So if it wasn't for the Mozilla mission, I'd state now that
Chrome probably is the better alternative for mobile than what is
planned for Firefox.
Chrome probably is the better alternative for mobile than what is
planned for Firefox.
Asa Dotzler
Oct 28, 2011, 1:31:10 PM10/28/11
to
Robert Kaiser wrote:
> Matt Brubeck schrieb:
>> On 10/28/2011 09:17 AM, Robert Kaiser wrote:
>>> Asa Dotzler schrieb:
>>>> You don't have to have XUL to have "webby" add-ons. I've been poking
>>>> around in Chrome add-ons and they're more "webby" than XUL add-ons.
>>>
>>> So most of their add-ons are implemented using a markup language and
>>> CSS? as _that_ is "webby". Most JS - even on the web - isn't.
>>
>> Yes, and the markup language is HTML. See the documentation for some
>> examples:
>>
>> http://code.google.com/chrome/extensions/getstarted.html
>
>
> Interesting. So if it wasn't for the Mozilla mission, I'd state now that
> Chrome probably is the better alternative for mobile than what is
> planned for Firefox.
Robert, there's nothing in the "native UI" that prevents us from having
> Matt Brubeck schrieb:
>> On 10/28/2011 09:17 AM, Robert Kaiser wrote:
>>> Asa Dotzler schrieb:
>>>> You don't have to have XUL to have "webby" add-ons. I've been poking
>>>> around in Chrome add-ons and they're more "webby" than XUL add-ons.
>>>
>>> So most of their add-ons are implemented using a markup language and
>>> CSS? as _that_ is "webby". Most JS - even on the web - isn't.
>>
>> Yes, and the markup language is HTML. See the documentation for some
>> examples:
>>
>> http://code.google.com/chrome/extensions/getstarted.html
>
>
> Interesting. So if it wasn't for the Mozilla mission, I'd state now that
> Chrome probably is the better alternative for mobile than what is
> planned for Firefox.
"webby" extensions. Chrome is native UI and they have webby extensions.
A XUL UI is not a requirement for supporting webby extensions.
- A
Mark Finkle
Oct 28, 2011, 3:53:52 PM10/28/11
to Gervase Markham
On 10/28/2011 12:12 PM, Gervase Markham wrote:
> On 27/10/11 16:44, Mark Finkle wrote:
>> Here is some current information, subject to change of course.
>
> Thanks - this is very informative.
>
>>> - Is the XUL UI going to be abandoned, or are we developing the two in
>>> parallel? Arguments against abandoning it include all the same
>>> cross-platform ones against abandoning XUL on the desktop, plus also
>>> that presumably we need a XUL-based browser UI for B2G.
>>
>> # The XUL UI will live on in the Mozilla source repo. The XUL UI is used
>> for Maemo/Meego and is still actively being maintained by Mozilla[1] and
>> contributors. We plan to add the Native UI code to mozilla-central in a
>> way that does not obsolete the XUL UI code.
>
> So just to be clear: even when the native UI is shipping on Android
> phones and tablets, Mozilla plans to officially maintain the XUL UI
> alongside?
Some clarity is needed here. At that point Mozilla won't be officially
> On 27/10/11 16:44, Mark Finkle wrote:
>> Here is some current information, subject to change of course.
>
> Thanks - this is very informative.
>
>>> - Is the XUL UI going to be abandoned, or are we developing the two in
>>> parallel? Arguments against abandoning it include all the same
>>> cross-platform ones against abandoning XUL on the desktop, plus also
>>> that presumably we need a XUL-based browser UI for B2G.
>>
>> # The XUL UI will live on in the Mozilla source repo. The XUL UI is used
>> for Maemo/Meego and is still actively being maintained by Mozilla[1] and
>> contributors. We plan to add the Native UI code to mozilla-central in a
>> way that does not obsolete the XUL UI code.
>
> So just to be clear: even when the native UI is shipping on Android
> phones and tablets, Mozilla plans to officially maintain the XUL UI
> alongside?
maintaining the XUL UI, but the code will be in the Mozilla source-repo.
We only need to officially maintain the XUL UI until the Java UI is
shipping on phones and tablets.
The code will be available for other maintainers to keep moving forward,
if any will exist at that point.
>>> - Do we plan to reimplement all UI natively, or just the
>>> performance-critical main window?
>>
>> # We plan on implementing all chrome UI using native widgets.
>
> Is this because it's easier than having a hybrid UI?
>
> It seems to me that the motivations for native UI apply far more
> strongly to the main window than the rest of the UI. That's the bit that
> needs to appear quickly on startup, and which deals with scrolling.
>
> If we keep the rest of the UI in XUL, we would have far fewer problems
> with the effort of maintaining two UIs, and with addons which wanted to
> support both desktop and mobile having to deal with two UIs.
the UIs synced is not easy, for example. We already struggle to make XUL
UIs look like native UIs anyway. Finally, the "line" where native UIs
stop and XUL UIs would start would constantly be challenged and
contested. It's a slippery slope and we feel it's better to go all the
way now.
Maintaining two systems of UI (native and XUL) is in no way simpler than
doing one or the other.
> I realise there are plans to support addons using new APIs, but why
> create new APIs if we can just keep the old ones?
few APIs for add-ons. XPCOM interfaces, like nsIAlertService, exist and
will still function. Much of the current APIs for UI are raw DOM or XUL
overlays or whatever JSMs might exist. Many are not considered frozen
and could change at any time. This is why efforts like Jetpack exist.
We plan to make some docs on what add-ons can and can't do in the native UI.
> Of course, it's not a free lunch, but I'd be interested to understand
> why this option was discarded.
to make the add-on experience in the native UI pretty damn nice. Given
those goals, trying to keep parts of the XUL UI around just to support
some add-on extensibility isn't a good long term goal. We feel those
potential XUL UI parts aren't as important as extending the core chrome
UI anyway - so we must provide some extensibility mechanism for native UI.
HTH
Mark Finkle
Oct 28, 2011, 3:55:58 PM10/28/11
to Shmerl
Robert Kaiser
Oct 28, 2011, 4:51:29 PM10/28/11
to
Asa Dotzler schrieb:
that regard as the existing UI cannot be customized by an add-on via
"webby" technology like CSS or DOM. Damn, now I won't get to be a Chrome
fanboy in the end as they equally don't reflect our mission. Doesn't
make me like the "native" Android UI either, though.
As I have repeated many times, nobody will be able to argue me into
liking it, even though I'm seeing it's the kind of bad compromise we
need to make to get something usable on low-perf Android devices. Sadly,
IMHO, the only thing that will make it better than Google's browser is
the organization behind it and not the product itself.
> Robert, there's nothing in the "native UI" that prevents us from having
> "webby" extensions.
Right, both Chrome and "our" future Android UI are equally non-webby in
> "webby" extensions.
that regard as the existing UI cannot be customized by an add-on via
"webby" technology like CSS or DOM. Damn, now I won't get to be a Chrome
fanboy in the end as they equally don't reflect our mission. Doesn't
make me like the "native" Android UI either, though.
As I have repeated many times, nobody will be able to argue me into
liking it, even though I'm seeing it's the kind of bad compromise we
need to make to get something usable on low-perf Android devices. Sadly,
IMHO, the only thing that will make it better than Google's browser is
the organization behind it and not the product itself.
Robert Kaiser
Oct 28, 2011, 4:54:07 PM10/28/11