B2G UI
Ben Francis
But because Chromeless is intended for building a collection of cross platform desktop applications using web technologies there is quite a lot of stuff in there which isn't really necessary for building a monolithic graphical shell for one platform.
What do you think would be needed in order to bootstrap an environment where the "chrome" could be written in HTML, CSS and JavaScript but with the kinds of extra privileges and capabilities which were being experimented with in Chromeless? (giving extra privileges to top level iFrames for example).
ya knygar
i think - B2G won't be finally for a one platform as it just could
combine the MOWA (Mozillalabs Open Web Apps) with Chromeless and
mobiles is just a great (by decision) start platform,
it won't be much different for desktop and would be used for it also,
i think. Just - it could be like platform in platform - i mean - just
an app for existing desktop OS.
If i correctly understood you - monolithic shell isn't the intent of
B2G (it's not B2F, by the way).
> What do you think would be needed in order to bootstrap an environment where the "chrome" could be written in HTML, CSS and JavaScript but with the kinds of extra privileges and capabilities which were being experimented with in > Chromeless? (giving extra privileges to top level iFrames for example).
I think - that correlates with my proposition of Web Apps as All on
GUI side of the OS. I propose to wait and see the first release from
B2G team, than - fork and see :)
Robert Kaiser
> But because Chromeless is intended for building a collection of cross platform desktop applications using web technologies there is quite a lot of stuff in there which isn't really necessary for building a monolithic graphical shell for one platform.
I think there are no plans as of now to create a monolithic
environment... Monolithic sounds so opposite to "webby" to me. ;-)
> What do you think would be needed in order to bootstrap an environment where the "chrome" could be written in HTML, CSS and JavaScript but with the kinds of extra privileges and capabilities which were being experimented with in Chromeless? (giving extra privileges to top level iFrames for example).
I think a lot of the features of XUL need to be (re)created in HTML to
make this happen smoothly.
Tree elements that are still fast when they hold large amounts of data,
have a simple way to be programmatically filled/controlled but are still
quite flexible are on thing where XUL is better right now (though <tree>
misses out on display flexibility there) and where HTML needs to be
improved.
"Native" (consistent with some global settings) look and still easy
theming across all apps is another.
Overlays are yet another.
If we can make open, standardized HTML match or overshoot XUL's
capabilities, UI design in HTML will be really fun.
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! :)
Mike Shaver
system, because nobody is going to implement XUL in another browser (with
good reason). Even we don't expose it to the web any longer, thankfully.
Much of XUL's capability (support for large datasets, menu bars) isn't
needed at this time, and other parts (flexbox) are coming to HTML. We
should bring the rest along as we need it, for the benefit of all of the
web.
Mike
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Axel Hecht
> Our plan is to use HTML for the UI. Using XUL would limit the reach of the
> system, because nobody is going to implement XUL in another browser (with
> good reason). Even we don't expose it to the web any longer, thankfully.
What does that mean for l10n? Are we constraining ourselves in what we
can think up here to infrastructure that another browser would also
implement?
Axel
Mike Shaver
> On 28.07.11 16:22, Mike Shaver wrote:
>>
>> Our plan is to use HTML for the UI. Using XUL would limit the reach of
>> the
>> system, because nobody is going to implement XUL in another browser (with
>> good reason). Even we don't expose it to the web any longer, thankfully.
>
> What does that mean for l10n? Are we constraining ourselves in what we can
> think up here to infrastructure that another browser would also implement?
I would expect so, and expect that it be something that can be done in
"userspace" (at the web app or web library layer). I thought L20N was
headed that way anyway, but I could be wrong.
(http://people.mozilla.com/~axel/l20n/js-l20n/sample-01.html f.e.)
I'm speaking here about the *B2G project*, not future possible
products based on the code or the experience; the latter would be
premature.
Mike
Robert Kaiser
> Our plan is to use HTML for the UI. Using XUL would limit the reach of the
> system, because nobody is going to implement XUL in another browser (with
> good reason). Even we don't expose it to the web any longer, thankfully.
>
> Much of XUL's capability (support for large datasets, menu bars) isn't
> needed at this time, and other parts (flexbox) are coming to HTML. We
> should bring the rest along as we need it, for the benefit of all of the
> web.
I fully second that, and esp. the last sentence is what I wanted this to
get to. I hope we're successful with the full extent of what you state
here! :)
(And I guess "needed at this time" is meant in terms of B2G project
focus, as I have seen a number of cases where people writing web
apps/sites have strongly voiced that they'd love to see improvements.)
Ben Francis
> I think there are no plans as of now to create a monolithic
> environment... Monolithic sounds so opposite to "webby" to me. ;-)
Sorry, maybe monolithic is the wrong word - I just meant to distinguish between the apps and the environment they run in. B2G apps will of course be standard web applications hosted on a server and cached locally, but I'm guessing there will be a need for some kind of local shell used for launching, navigating and switching between those apps, configuring system-wide settings etc.
My personal view is that this "shell" should be as minimalistic as possible, and really try to keep out of the way in order to let the apps themselves dominate the experience, but I think a shell of some kind is probably still required.
I was wondering if something along the lines of Chromeless could be used to bootstrap an outer Gecko container to render the chrome of that shell (itself written in HTML/CSS/JavaScript) which is then used to launch the apps (perhaps within iFrames which the shell has special privileges over in order to facilitate navigation).
Ben
Axel Hecht
> On Thu, Jul 28, 2011 at 10:36 AM, Axel Hecht<l1...@mozilla.com> wrote:
>> On 28.07.11 16:22, Mike Shaver wrote:
>>>
>>> Our plan is to use HTML for the UI. Using XUL would limit the reach of
>>> the
>>> system, because nobody is going to implement XUL in another browser (with
>>> good reason). Even we don't expose it to the web any longer, thankfully.
>>
>> What does that mean for l10n? Are we constraining ourselves in what we can
>> think up here to infrastructure that another browser would also implement?
>
> I would expect so, and expect that it be something that can be done in
> "userspace" (at the web app or web library layer). I thought L20N was
> headed that way anyway, but I could be wrong.
> (http://people.mozilla.com/~axel/l20n/js-l20n/sample-01.html f.e.)
The prototype there was really just that, and is probably quite horrible
perf-wise. gandalf is currently working on getting this hooked up in
content.
> I'm speaking here about the *B2G project*, not future possible
> products based on the code or the experience; the latter would be
> premature.
For b2g, having something optimized in gecko should be cool, right? That
is, assuming that we can create a shim lib that emulates that on other
engines, if we can't convince them to use the same infra?
Axel
ya knygar
> there will be a need for some kind of local shell used for launching, navigating and switching between those apps, configuring system-wide settings etc.
I think - for performance - it's in a purpose of modern markup/JS "compilers".
- for customization - it's better to give the API's to developers of
particular apps that would be
used to configure the kind of what is now in "about:config", along
with apps for telephony and
other parts,
it's obvious that people are in fond of customization for their
fingers/habits/mood's
- easy customization of every aspect of OS and - especially - GUI.
I'v seen the thread of JetPack SDK and it's evolving into SDK of
browser itself,
("Firefox front-end features, time-to-market, and coordination")
browser, in order - could be contained from parts that are - like
add-ons now, i think - it could be hard
to leverage (it's a mobile, still - highly performance depended,
project) but it, could, introduce the
significant benefits for this project, also.
(and - could be done by Mozilla if by any, if you don't mind)
> My personal view is that this "shell" should be as minimalistic as possible, and really try to keep out of the way in order to let the apps themselves dominate the experience, but I think a shell of some kind is probably still required.
If this project would give to Apps the ability to dictate the whole
experience, including style of the system clock - it would be great,
if this project would give to add-ons of the project's Browser - the
ability to customize the app - for the experience, it would be nice,
also,
I see - both variants are possible and they are the best ways to "let
the apps themselves dominate the experience" and GUI to be "..as
minimalistic as possible"
what do you think?
Michael Couch
anymore. Here are the suggestions...
1. Use the Chuck Moore chip at GreenArray144chip.com chip. It is 144
parallel 18 bit asynchronous CPUs with a maximum throughput of 96
GigaInstructions per second. They are $20 with a minimum order of 10
chips.
It has only 33 instructions to master but the thought pattern for
programming may be a bit strange it is a FORTH system. The chip has
several built in i/o methods.
Forth is the language that OS bootloaders are written in. It is very
powerful and very compact and very fast.
2. Built a stadalone Audio Google interface or one that is search
engine independent. My name for it is G3PO. The idea is a companion
robot UI that mimics G3PO behavior as a front end to Google that uses
Speech to Text and Text to Speech efficiently to operate a Search
engine and surf the web allowing people to Jog and Surf the Web, etc.
or just to keep working after their eyes are exhausted, assiting the
blind etc. There is already an open source effort that has proceeded a
long way down this road but I have not caught up with current status
in a couple years. This is not an easy task given the clutter on most
websites.
In my opinion the whole need for a new OS (and IMO every platform
needs a new OS) is because of Bloat, massive bloat. Building an OS
from the bottom up to do the essential things well at maximum speed
with minimal resources should be the goal.
An efficient programming tool should be a part of the OS too. So many,
people know how to code in some language, it is very frustrating to
get a system that has no included SUSCINCT high level language. Most
of them are bloated to the point of uselessness for novices and
encumbered with "structured" coding overhead, etc. Even ANSII forth
suffers from this as people tried to turn it into C instead of
learning how to program in Forth.
I think Forth has a flaw in that it is not inherently easy to use
variables though and a new language (a very close to the hardware
variation of Forth with a better DEV) should be adopted that either
uses another "variable stack" solve the oft situtation where you just
need one or two variables but end up having to do contortions with the
stack to get them into the immediate operation.
If you guys take my advice, please keep the kernel very small and
tight, then have the libraries add just what is needed for the
application loaded on demand.
3. Finally, there is a 3D web browser under Open Source development (I
think) in Germany or Norway somewhwere, it is really cool. I'll try to
find the URL and post it here. Maybe it could be rolled into the OS.
Michael Couch
Benjamin Smedberg
> I joined this group to make a few suggestions, I'm not much of a coder
> anymore. Here are the suggestions...
however interesting, are firmly offtopic. Please let's discontinue all
parts of the B2G thread which relate to hardware and low-level
bootloader/operating system discussion: at least at this phase of the
project these discussions are completely unhelpful.
--BDS