You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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?
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! :)
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
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. ;-)
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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?
I started a wiki page about add-on support in the new UI at https://
. Inputs welcome!
Fabrice
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to dev-platfo...@lists.mozilla.org
Makoto Kato unread, Oct 17, 2011, 9:19:37 AM10/17/11 You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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?
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Asa Dotzler schrieb:
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to flod, dev-platfo...@lists.mozilla.org
Axel Hecht unread, Oct 17, 2011, 4:01:44 PM10/17/11 You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Hi flod,
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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,
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.
Good catch, need to look. Added.
> - How do you plan to test this? I'm worried, in particular considering
> the new release cycle.
Yeah.
Axel
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
Shmerl unread, Oct 17, 2011, 6:29:35 PM10/17/11 You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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).
> - 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.
>
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
This move also concerns many others...
T'would be great if this post could be addressed by Mozilla reps
charged w/this new direction?
Thank-you.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Any news from last Friday meeting?
Francesco
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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.
> 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.
# 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 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)?
# The XUL UI will be used in the Fx8, Fx9 and Fx10 releases on phones
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 implementing all chrome UI using native widgets.
# 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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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.
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
.
Which repos, when, etc are all in TBD, we're meeting on a weekly basis
for now.
Axel
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Shmerl schrieb:
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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 unread, Oct 28, 2011, 6:12:49 PM10/28/11 You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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.
>> - 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?
>> - 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.
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
examples:
http://code.google.com/chrome/extensions/getstarted.html
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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://
Fabrice
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
"webby" extensions. Chrome is native UI and they have webby extensions.
A XUL UI is not a requirement for supporting webby extensions.
- A
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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.
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.
> I realise there are plans to support addons using new APIs, but why
> create new APIs if we can just keep the old ones?
By old APIs you must mean "anything goes" because we currently have very
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.
Many of the developers on the Mobile team are big add-on fans. We plan
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Shmerl
We have no plans for a Qt, or any other port, at the moment.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Asa Dotzler schrieb:
> 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
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Fabrice Desré schrieb:
> 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
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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,
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Shmerl schrieb:
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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.
I certainly don't argue that it would be simpler! But if we end up
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.
Well, "anything goes" is rather what distinguishes Firefox from the
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Isn't XUL already a rather generic notation? If one would need 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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
How is Fennec connecting the Native UI (Java) with Gecko? Is it reviving
the Embedding API, creating a new one or something else?
Philipp
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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.
It just seems like too big a compromise to the organization's core principles :(
Asa Dotzler unread, Nov 3, 2011, 4:15:28 PM11/3/11 You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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.
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.
> 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. 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.
Yes, you're probably correct here. I'd also note that Windows and Mac
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.
Mozilla promotes open source values. We are an open source project and
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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.
This is a better reply :-) But when the Foundation was down to 7 people,
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
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
"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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
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.
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
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
somehow as well and can it benefit Android?
Regards,
Hillel.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4