info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Native UI on Android
493 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
to
Fabrice Desré schrieb:
> I'd be intersted in having you contribute, for instance here: https://
> wiki.mozilla.org/Fennec/NativeUI/addons
I surely won't contribute actively in any way to that native UI project.
I will do my duty in investigating crashes, but that's all.
If I have any free time left to actively contributing anywhere mobile,
it will be non-Android and/or B2G stuff for sure.
> 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 ;)
Sounds like "we suck and therefore don't need to do better anyhow". :p
> 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
I will do my duty in investigating crashes, but that's all.
If I have any free time left to actively contributing anywhere mobile,
it will be non-Android and/or B2G stuff for sure.
Shmerl
Oct 28, 2011, 4:40:49 PM10/28/11
to
On Oct 28, 3:53 pm, Mark Finkle <mark.fin...@gmail.com> wrote:
> > 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
> 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.
This sounds like you single out Android as the only worthy platform,
> > 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
> 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.
leaving the rest up to finding maintainers for XUL UI, which hopefully
might work out, but as well might not. The problem I see with it, is
loosing Firefox portability, since Mozilla can't promise supporting
every emerging platform with native UI layer. I'd expect the opposite
from Mozilla - to maintain and support XUL as a portable layer, and to
look for maintainers for native UIs. This will allow platform with
smaller developer base to use portable XUL, and platforms with bigger
bases finding maintainers for native UI.
Regards,
Hillel.
Robert Kaiser
Oct 28, 2011, 6:06:02 PM10/28/11
to
Shmerl schrieb:
really significant market share.
I'd also hope for Mozilla to offer cross-platform products but it looks
like the mobile team has decided that it is unable to follow that in the
face of needing to get some foothold in the mobile mass market and the
current solution not bringing the performance we need.
I'm about as sad (if not enraged) about that as you seem to be, but I
guess only the community will be able to keep Mozilla really open to
other alternatives.
And then there's B2G, which goes in a completely different direction and
hopefully will succeed in providing a really innovative and Open Web
alternative on mobile devices - if we can drive it to the mass market.
> This sounds like you single out Android as the only worthy platform
Right now it's the only platform we can provide a browser on that has
really significant market share.
I'd also hope for Mozilla to offer cross-platform products but it looks
like the mobile team has decided that it is unable to follow that in the
face of needing to get some foothold in the mobile mass market and the
current solution not bringing the performance we need.
I'm about as sad (if not enraged) about that as you seem to be, but I
guess only the community will be able to keep Mozilla really open to
other alternatives.
And then there's B2G, which goes in a completely different direction and
hopefully will succeed in providing a really innovative and Open Web
alternative on mobile devices - if we can drive it to the mass market.
Shmerl
Oct 30, 2011, 1:45:53 PM10/30/11
to
On Oct 28, 6:06 pm, Robert Kaiser <ka...@kairo.at> wrote:
> I'm about as sad (if not enraged) about that as you seem to be, but I
> guess only the community will be able to keep Mozilla really open to
> other alternatives.
Yes, it saddens me that there is a high risk now, that mobile Linux
> I'm about as sad (if not enraged) about that as you seem to be, but I
> guess only the community will be able to keep Mozilla really open to
> other alternatives.
will be left out without Firefox option on tablets and handsets,
because Android is singled out as the only worthy candidate.
Android hinders mobile Linux adoption as it is already, with GPU
drivers lack, hardware manufacturers distraction and so on, but while
mobile Linux had many setbacks because of Nokia dropping Meego, and
other obstacles, it slowly starts to gain momentum now with KDE Plasma
Active, Tizen announcement, Nemo/Mer projects and so on. But if mobile
XUL UI will fall behind - Firefox won't be an option there.
Maintaining it is not an easy feat, and if Mozilla drops the ball -
I'm not sure anyone will be able to compensate it.
Regards,
Hillel.
Oleg Romashin
Oct 31, 2011, 7:47:17 PM10/31/11
to
Would be nice to write UI using some pseudo description language, and
then have some convertor Pseudo -> Android XML, QML, ... which
supposed to create native platform objects with common API's
And then Native FF code could be generic and fast at the same time...
Br, Oleg
then have some convertor Pseudo -> Android XML, QML, ... which
supposed to create native platform objects with common API's
And then Native FF code could be generic and fast at the same time...
Br, Oleg
Gervase Markham
Nov 1, 2011, 7:22:22 AM11/1/11
to
On 28/10/11 20:53, Mark Finkle wrote:
> Some clarity is needed here. At that point Mozilla won't be officially
> 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.
If you define "need" as "what we need to support Android", then I guess
> Some clarity is needed here. At that point Mozilla won't be officially
> 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.
this is true.
If we define "need" as "needing to have the ability to be flexible, and
quickly port to new mobile operating systems as they become available",
then it's less so. I'm no industry insider, but it seems to me that the
mobile OS space is currently in a considerable amount of flux. And that
it might be good if we didn't make it an enormous amount of work for
people to use our browser rather than a Webkit-based one when bringing
up the apps for a new platform.
Or to look at it another way, with Android moving towards a more closed
model of development, a risk of which Mozilla is well aware, why are we
betting the farm on it?
> Yes. A hybrid approach opens news areas of pain. Keeping the "style" of
> 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.
supporting 2, 3 or 4 mobile platforms (and I hope we will - promoting
choice, supporting systems which agree with our ideals, etc.), it would
start to be less work than supporting 2, 3 or 4 entire native front-ends.
> By old APIs you must mean "anything goes" because we currently have very
> few APIs for add-ons.
competition (at least on the desktop) and gives it its power. Both this
route and a Chrome-like "standard API" route have their pros and cons,
but if we go their way, we will find it hard to be significantly better
than them.
The fact that people can mess with the internals of our platform is a
differentiating feature, not a bug. Jetpack helps those whose
requirements are simple and whose level of commitment is lower - and
that's great. But if it was all there was, we'd lose one of our key
differentiators.
So I hope that the native UI will not move to an add-on model of "here
are the 17 functions you can call; if what you want isn't there, tough
luck".
Gerv
Shmerl
Nov 1, 2011, 11:33:51 AM11/1/11
to
write a translator, it can start from XUL which already exists. Static
markup probably is not the biggest issue, but the tricky part is, how
to map JavaScript behaviors into other languages.
Regards,
Hillel.
Philipp Wagner
Nov 1, 2011, 5:57:20 PM11/1/11
to
the Embedding API, creating a new one or something else?
Philipp
jedi....@gmail.com
Nov 3, 2011, 1:16:04 AM11/3/11
to
On Saturday, 29 October 2011 08:06:02 UTC+10, Robert Kaiser wrote:
> I'd also hope for Mozilla to offer cross-platform products but it looks
> like the mobile team has decided that it is unable to follow that in the
> face of needing to get some foothold in the mobile mass market and the
> current solution not bringing the performance we need.
So don't compete on performance, compete on feature-set, extensibility etc.
> I'd also hope for Mozilla to offer cross-platform products but it looks
> like the mobile team has decided that it is unable to follow that in the
> face of needing to get some foothold in the mobile mass market and the
> current solution not bringing the performance we need.
It just seems like too big a compromise to the organization's core principles :(
Asa Dotzler
Nov 3, 2011, 11:15:28 AM11/3/11
to
compromised by Mozilla trying to well support an additional software
platform? I'm reading the Mozilla Manifesto's Principles and Pledge, and
the Mozilla Mission Statement and I can't find them.
- A
Shmerl
Nov 3, 2011, 1:53:39 PM11/3/11
to
On Nov 3, 11:15 am, Asa Dotzler <a...@mozilla.com> wrote:
> Jedi, can you point me to the specific Mozilla core principles that are
> compromised by Mozilla trying to well support an additional software
> platform? I'm reading the Mozilla Manifesto's Principles and Pledge, and
> the Mozilla Mission Statement and I can't find them.
>
> - A
I believe the manifesto has references to general approval of open
> Jedi, can you point me to the specific Mozilla core principles that are
> compromised by Mozilla trying to well support an additional software
> platform? I'm reading the Mozilla Manifesto's Principles and Pledge, and
> the Mozilla Mission Statement and I can't find them.
>
> - A
source and open development approach:
* The effectiveness of the Internet as a public resource depends upon
interoperability (protocols, data formats, content), innovation and
decentralized participation worldwide.
* Free and open source software promotes the development of the
Internet as a public resource.
* Transparent community-based processes promote participation,
accountability, and trust.
The problem is not making Android well supported, but degrading
support for more open platforms. Making Android the exclusive target
for mobile efforts is not really promoting community based processes,
collaboration, free software and so on. Android is much more
proprietary in nature, than real mobile Linux like Meego, Nemo and so
on. For example one of the worst disadvantages of Android from the
open source and collaborative perspective is using totally
incompatible graphical stack (instead of Wayland for example), and not
sharing any effort with the global Linux community. Porting free OSes
to Android devices is often hindered by manufacturers being focused on
Android only (drivers wise) and so on.
So I do believe Mozilla still considers promoting open source values
important.
Regards,
Hillel.
Asa Dotzler
Nov 3, 2011, 11:01:57 PM11/3/11
to
Shmerl wrote:
> On Nov 3, 11:15 am, Asa Dotzler<a...@mozilla.com> wrote:
>> Jedi, can you point me to the specific Mozilla core principles that are
>> compromised by Mozilla trying to well support an additional software
>> platform? I'm reading the Mozilla Manifesto's Principles and Pledge, and
>> the Mozilla Mission Statement and I can't find them.
>>
>> - A
>
> I believe the manifesto has references to general approval of open
> source and open development approach:
Yes. You're correct. And there's nothing in what we're doing with
> On Nov 3, 11:15 am, Asa Dotzler<a...@mozilla.com> wrote:
>> Jedi, can you point me to the specific Mozilla core principles that are
>> compromised by Mozilla trying to well support an additional software
>> platform? I'm reading the Mozilla Manifesto's Principles and Pledge, and
>> the Mozilla Mission Statement and I can't find them.
>>
>> - A
>
> I believe the manifesto has references to general approval of open
> source and open development approach:
Android support that is in conflict with open source, interoperability,
or a community-based process.
> * The effectiveness of the Internet as a public resource depends upon
> interoperability (protocols, data formats, content), innovation and
> decentralized participation worldwide.
> * Free and open source software promotes the development of the
> Internet as a public resource.
> * Transparent community-based processes promote participation,
> accountability, and trust.
its resources into making the best possible experience it can on
Android? I'm not seeing it.
> The problem is not making Android well supported, but degrading
> support for more open platforms. Making Android the exclusive target
> for mobile efforts is not really promoting community based processes,
> collaboration, free software and so on.
to support well. If you want to maintain a XUL front end or even a
native front end for Meego, Mozilla will help you with build resources,
hosting, and even technical assistance, as we do for various other ports
like OS/2, OpenSolaris, or PPCMac. But there's nothing in Mozilla's core
principles that requires Mozilla put resources into advancing the cause
of every open source operating systems.
> Android is much more proprietary in nature, than real mobile Linux like
> Meego, Nemo and so on.
are much more proprietary than OpenBSD. Yet Windows and Mac are where
the users are and that's where Mozilla puts a large part of its limited
resources. That doesn't preclude those who support OpenBSD or Meego from
continuing to make Firefox available to those users.
> So I do believe Mozilla still considers promoting open source values
> important.
we build open source products. We even build open source products for
open source operating systems with very little relative market share
(see Linux.)
Yes, we have open source values and we believe those are not just
important but that they're critical to our ability to be effective in
our Mission.
- A
Gervase Markham
Nov 4, 2011, 9:07:19 AM11/4/11
to Asa Dotzler
On 04/11/11 03:01, Asa Dotzler wrote:
>> * The effectiveness of the Internet as a public resource depends upon
>> interoperability (protocols, data formats, content), innovation and
>> decentralized participation worldwide.
>> * Free and open source software promotes the development of the
>> Internet as a public resource.
>> * Transparent community-based processes promote participation,
>> accountability, and trust.
>
> And you assert that these principles are compromised when Mozilla puts
> its resources into making the best possible experience it can on
> Android? I'm not seeing it.
Come on Asa, you are wilfully missing his point here for the sake of
>> * The effectiveness of the Internet as a public resource depends upon
>> interoperability (protocols, data formats, content), innovation and
>> decentralized participation worldwide.
>> * Free and open source software promotes the development of the
>> Internet as a public resource.
>> * Transparent community-based processes promote participation,
>> accountability, and trust.
>
> And you assert that these principles are compromised when Mozilla puts
> its resources into making the best possible experience it can on
> Android? I'm not seeing it.
debate. He's not complaining about us trying to make a good experience
on Android.
>> The problem is not making Android well supported, but degrading
>> support for more open platforms. Making Android the exclusive target
>> for mobile efforts is not really promoting community based processes,
>> collaboration, free software and so on.
>
> There are no free lunches. We support the platforms as we have resources
> to support well.
we still supported Windows, Mac and Linux - even if we could perhaps
have supported Windows better by dropping any effort on the other two.
So this is not the final word on the matter.
No goal is so important that it occludes all others - not even "the best
user experience on Android". What people are trying to have here is a
debate about the relative importance of various good things.
The question is not "should we make an awesome browser on Android or
not?", the questions are:
"is the time saved by stopping work on the XUL UI worth the loss of
portability, and the corresponding flexibility we have to quickly react
to market share changes in the mobile market, and also the loss of the
ability for people to take Firefox quickly to new platforms, and thereby
have some chance of that platform not being Yet Another Webkit Platform?"
and also:
"how do we do the native Android UI in such a way as to have as few
Android-specific parts as possible"?
The team are actually tackling this second question; I note from their
meeting minutes that they are trying hard to write all their glue in JS,
to maximise the possibility of reuse underneath another widget set.
Gerv
![Paul [sabret00the]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXpqWEkVBU_5J5Xax-9ym-MBL8B7zIo97fdWeD9T1Mf9Te1mTw=s40-c)
Paul [sabret00the]
Nov 4, 2011, 9:23:20 AM11/4/11
to Asa Dotzler
> "how do we do the native Android UI in such a way as to have as few
> Android-specific parts as possible"?
>
> The team are actually tackling this second question; I note from their
> meeting minutes that they are trying hard to write all their glue in JS,
> to maximise the possibility of reuse underneath another widget set.
>
> Gerv
For me, this is the most important thing. As long as there's an effort to make the work reusable, it might not be perfect, but it's fundamentally good for users and Mozilla as a whole.
> Android-specific parts as possible"?
>
> The team are actually tackling this second question; I note from their
> meeting minutes that they are trying hard to write all their glue in JS,
> to maximise the possibility of reuse underneath another widget set.
>
> Gerv
Mark Finkle
Nov 5, 2011, 1:08:38 AM11/5/11
to Gervase Markham, Asa Dotzler
On 11/04/2011 09:07 AM, Gervase Markham wrote:
> "how do we do the native Android UI in such a way as to have as few
> Android-specific parts as possible"?
>
> The team are actually tackling this second question; I note from their
> meeting minutes that they are trying hard to write all their glue in JS,
> to maximise the possibility of reuse underneath another widget set.
Thank you for noticing. There are people thinking about how to port the
> "how do we do the native Android UI in such a way as to have as few
> Android-specific parts as possible"?
>
> The team are actually tackling this second question; I note from their
> meeting minutes that they are trying hard to write all their glue in JS,
> to maximise the possibility of reuse underneath another widget set.
"native" architecture we are using on Android to other platforms. The
Mozilla Mobile team doesn't have the time at the moment to be those
people, but some are certainly interested in seeing this happen.
I'd personally be interested in getting people who do have some time and
skills to try it out on other platforms, like Qt or .NET - or whatever.
I also can't promise Mozilla would ever officially uplift such projects.
I will say this: The issues we see on Android which have led us to the
native UI approach are not limited to Android. I mean, any serious
effort by Mozilla on a new mobile platform would likely result in the
same "native" approach. Android is not the exception.
Matt Brubeck
Nov 5, 2011, 2:09:23 AM11/5/11
to
On 11/04/2011 10:08 PM, Mark Finkle wrote:
> I will say this: The issues we see on Android which have led us to the
> native UI approach are not limited to Android. I mean, any serious
> effort by Mozilla on a new mobile platform would likely result in the
> same "native" approach. Android is not the exception.
This is an important point. On Maemo, for example, there are two Gecko
> I will say this: The issues we see on Android which have led us to the
> native UI approach are not limited to Android. I mean, any serious
> effort by Mozilla on a new mobile platform would likely result in the
> same "native" approach. Android is not the exception.
browsers. Firefox uses XUL for its UI, and often takes over 10 seconds
to start up on the N900. MicroB used the "native UI" approach, and has
markedly better performance in startup and other areas. (I should note
that MicroB also use other techniques like starting a background service
at boot time, so this is not a pure native-versus-xul comparison.)
Oleg Romashin, who worked on both MicroB and Firefox for Maemo, has
argued before in favor of some of MicroB's choices. Last week he started
a thread on mozilla.dev.platform about a portable API he's developed
that could be used for similar native UI Gecko browsers on any platform.
Personally, I am spending part of my time keeping the XUL Fennec code
alive and maintained, because we need to keep shipping platform and
security updates to our existing Android users while the native
front-end is still in development. While Mozilla staff aren't working
on new features for XUL Fennec right now, I'm happy to help review
patches and provide other assistance for those who are still actively
working with that code base, including the Meego community.
Shmerl
Nov 9, 2011, 12:17:13 PM11/9/11
to
On Nov 5, 1:09 am, Matt Brubeck <mbrub...@mozilla.com> wrote:
> Oleg Romashin, who worked on both MicroB and Firefox for Maemo, has
> argued before in favor of some of MicroB's choices. Last week he started
> a thread on mozilla.dev.platform about a portable API he's developed
> that could be used for similar native UI Gecko browsers on any platform.
>
That portable IPC API sounds very interesting. Can Mozilla use it
> Oleg Romashin, who worked on both MicroB and Firefox for Maemo, has
> argued before in favor of some of MicroB's choices. Last week he started
> a thread on mozilla.dev.platform about a portable API he's developed
> that could be used for similar native UI Gecko browsers on any platform.
>
somehow as well and can it benefit Android?
Regards,
Hillel.
0 new messages