Prism is now Chromeless
Lloyd Hilaiel
Prism, and simultaneously to widen the goals of Chromeless:
http://mozillalabs.com/blog/2011/02/prism-is-now-chromeless/
I wanted to reach out to folks on this list and get your thoughts
on the change.
curiously,
lloyd
skeeJay
seems to reflect a trend in browser development and mobile development
abandoning innovation toward "cloud" apps in favor of "installable"
apps.
I would have liked to see Prism continue in the context of apps with
HTML5 offline support—literally, Web apps that abstracted the concept
of being online or offline away from the user. Moving to app stores
and installable apps seems to further fragment the different versions
an app developer must now build for—Web app, mobile Web app, native
mobile app, and now installable browser app. Is there an advantage
I'm missing?
E J Kalafarski
blog.ejkalafarski.com
Flyboy
be incredibly useful for the development of desktop applications, and
it's an awesome direction for Mozilla.
Rushyo
Chromeless is creatively a different entity actually providing less
technical functionality ('minimal' OS interaction) that is less mature
than Prism, relying mostly on capabilities that people expect from
their browsers naturally anyway. What value does Chromeless add over
Prism, other than the opportunity to start a fresh code base?
Ben Francis
Natanael L
platform and install with a single click!
With proper HTML5 offline support, we can make advanced games that you
can play both offline and online!
With the advances in JIT and javascript compiling and interpreting
performance, this can be a reality.
Complex games with cool graphics could really run anywhere! It would
be easier then ever to make new things!
Re Ben Francis: Cool! Do you have posted your ideas anywhere? I
actually have thought about the same thing before, to use XULRunner as
a base for a desktop enviroment that easily could be extended.
(FYI, I began to think about using XULRunner for it when I saw the
mini player that was detached from Firefox in the FoxyTunes addon,
that was when I realized that XULRunner could render the entire
desktop enviroment.)
Also, another cool thing would be the ability to install desktop
enviroments with a click and switch without logging out and in again.
And you could have the same one on all your computers. And synced with
Firefox Sync. :D
On 2 Feb, 14:31, Ben Francis <b...@tola.me.uk> wrote:
> If this means that Chromeless will continue to grow and mature then it
> sounds like a great thing to me!
>
> My use of Chromeless is perhaps a little unusual in that I'm using it to
Paul Morris
But I don't know enough about the open web apps. Do they, can they, provide the same functionality as prism? Can they provide a separate app/window without all the usual browser chrome like prism? Can a user turn any website into an open web app?
Just my thoughts,
-Paul
enefekt
Looking forward to how this builds on XULRunner.
Lloyd Hilaiel
Fair criticism. If you consider the specific use case of Prism (site
specific browsing), I think the key benefit in chromeless is that there
will be *more* APIs available, for OS interaction as well as other types
of tasks.
In my mind, one key technical difference between the two projects is the
number of layers. Chromeless adds a module system so that new APIs can
be exposed via javascript modules which can leverage components from the
xulrunner platform (via XPCOM), binaries (via JSCTYPES), or other modules.
This module system in chromeless is from the addon-sdk community who
have been refining it for over a year now.
My hope is that given that it's easier to extend chromeless, and that
there are now multiple projects using a compatible module format,
there will be a rich and fast growing set of API features.
Does that make sense?
lloyd
Lloyd Hilaiel
On Wed, Feb 02, 2011 at 06:54:27AM -0800, Paul Morris wrote:
> I support the work on open web apps and chromeless, but... As I
> understand it, prism lets *regular end users* with no coding knowledge
> create "separate applications in a distraction free browser window" out of
> whatever web sites/apps they want. Chromeless is meant for developers, so
> it doesn't (currently?) provide the same functionality to regular users.
> So it seems it's *open web apps* that would take over for prism, as far
> as most users are concerned? (Until developers start using chromeless to
> provide users with chromeless-based apps...)
You're right. Prism was end user facing, while chromeless currently is solidly
developer facing. As you mention, one way that SSBs can exist on top of chromeless
is by developers producing standalone apps.
Another interesting thing that someone might explore is assessing what
it would take to build a user-facing prism clone on top chromeless (we
could go nuts and start with the wide-eyed goal of having prism
.webapp bundles run unchanged). I think many/most of the new features
required in chromeless to support are things that are being/will be
built.
I think this thought experiment would be useful (and I daresay, fun!).
> But I don't know enough about the open web apps. Do they, can they,
> provide the same functionality as prism? Can they provide a separate
> app/window without all the usual browser chrome like prism? Can a user
> turn any website into an open web app?
There's been some interest in this feature, user initiated
"appification" of sites so that you can launch and mangage the sites
you use most right beside more "official" web applications. There's
also been talk about how applications might have different run modes,
like a "browser chrome free" mode. As far as functionality, we're
proposing a capabilities/permissions system where apps can request
permissions to do advanced things. "notifications", "desktop icons",
"tray icon badges", all of these do seem to me like things that could
plausibly become capabilities.
So as that post tries to convey, it does seem like these two experiements
approach the case of SSBs from both sides...
lloyd
> Just my thoughts,
> -Paul
>
> --
> You received this message because you are subscribed to the Google Groups
> "mozilla-labs" group.
> To post to this group, send email to mozill...@googlegroups.com.
> To unsubscribe from this group, send email to
> mozilla-labs...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mozilla-labs?hl=en.
Ben Francis
Cool! Do you have posted your ideas anywhere?
enefekt
interface toolkit?
Natanael L
much details yet.
I usually do it that way, I work on the concept and just a few details
first before I make something that makes sense to others out of it.
MarkC
for over 2 years now. It's due to see its first official release any
day now, and is already being rolled out to a few customers as a pre-
release. This is very much an intranet app that our customers install
on their own internal servers.
Many of our customers have an IT policy which prohibits the use of
Firefox for one reason or another. Most are happy to deploy a "runtime
environment" instead, for which we've been recommending Prism. Others
actively prefer Prism because, combined with remote XUL, it gives the
appearance of the product being a "normal" desktop app.
Can anyone tell me how this change is likely to impact our use of
Prism? Will Chromeless support remote XUL now that it's being disabled
in Firefox 4? If it's being disabled in Chromeless, will it be
possible to re-enable it?
Given that we don't necessarily know anything about our customers'
intranets, it's not possible for us to build an SSB pointing at a
fixed address. Does that mean that we'll end up with our customers
having to build Chromeless themselves? At least with Prism they can
just put their own server IP into a dialogue at the point of
deployment.
And what does this mean for the "Prism for Firefox" extension? For
those customers who are happy to have Firefox but prefer the minimal
UI of Prism, we've been suggesting this as the easiest way to get our
product running in that environment. Are there plans for a "Chromeless
for Firefox" extension to perform a similar trick?
I know, too many questions, some of which probably don't have answers
at this point. But having already had the rug pulled out from my 2+
years of development by the decision to drop remote XUL in Firefox 4,
my boss will want my head on a platter when I tell him that our
fallback option has been abandoned as well.
Mark
Lloyd Hilaiel
On Thu, Feb 03, 2011 at 07:42:56AM -0800, MarkC wrote:
> I've been working on a commercial remote XUL app (well, suite of apps)
> for over 2 years now. It's due to see its first official release any
> day now, and is already being rolled out to a few customers as a pre-
> release. This is very much an intranet app that our customers install
> on their own internal servers.
>
> Many of our customers have an IT policy which prohibits the use of
> Firefox for one reason or another. Most are happy to deploy a "runtime
> environment" instead, for which we've been recommending Prism. Others
> actively prefer Prism because, combined with remote XUL, it gives the
> appearance of the product being a "normal" desktop app.
>
> Can anyone tell me how this change is likely to impact our use of
> Prism? Will Chromeless support remote XUL now that it's being disabled
> in Firefox 4? If it's being disabled in Chromeless, will it be
> possible to re-enable it?
I feel like a great source of information re remote XUL lives in the
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=546857#c245
(specifically I thought Brendan's suggestion of an addon that fiddles a
whitelist to be pertinent, and hopefully, useful to you?)
Regarding "remote XUL" support in chromeless, no. One of the primary
things we wanted to explore in chromeless is application development
in HTML, which often means abstracting features that in XUL apps are
typically interfaced through the DOM (like menus and keybindings).
> Given that we don't necessarily know anything about our customers'
> intranets, it's not possible for us to build an SSB pointing at a
> fixed address. Does that mean that we'll end up with our customers
> having to build Chromeless themselves? At least with Prism they can
> just put their own server IP into a dialogue at the point of
> deployment.
Yeah, again you're calling out the fact that chromeless is a lower level
project than prism. So no, I don't think it's viable to have end users
interact directly with it. But it does seem like it would be very quick
to start a user-facing project in the spirit of prism on top of it...
> And what does this mean for the "Prism for Firefox" extension? For
> those customers who are happy to have Firefox but prefer the minimal
> UI of Prism, we've been suggesting this as the easiest way to get our
> product running in that environment. Are there plans for a "Chromeless
> for Firefox" extension to perform a similar trick?
I have no knowledge of such plans. But surely, something like that
could be undertaken. I'm curious if Open Web Apps, as they evolve,
might provide an easier and better way for users to turn sites into
apps?
> I know, too many questions, some of which probably don't have answers
> at this point. But having already had the rug pulled out from my 2+
> years of development by the decision to drop remote XUL in Firefox 4,
> my boss will want my head on a platter when I tell him that our
> fallback option has been abandoned as well.
I'm sorry recent decisions have affected you like this. I hope the
whitelist workaround helps ease your pain, and from my side would be
willing to support and contribute to a simple user facing version of
prism on top of chromeless.
very best,
lloyd
Taboca
I am interested in your case. I do not think it's unusual for my Chromeless desires ( aside from my priorities ). Can you elaborate a bit more in this thread or another thread? We recently added ability to drop files out to the OS folder. What features you interested in terms of OS?
BTW I filed your request in my bug tracking list ( ability to stop page load )
Marcio
Paul Morris
Thanks for the reply. Good to know how this breaks down in terms of users and developers. Sounds like clear wins for developers in the short and long term, while it may take time for users to start to directly benefit.
In the meantime I guess that prism will still be available for use, just not actively maintained (by Mozilla Labs at least, and I guess it probably won't receive the Firefox 4 treatment). Maybe later your idea of building a user-facing prism successor on top of chromeless will become a reality? I like that idea, and also the option for users being able to "app-ify" any website they choose on the web apps front.
Looking forward to seeing it all develop!
-Paul
MarkC
> I feel like a great source of information re remote XUL lives in the
> bug:https://bugzilla.mozilla.org/show_bug.cgi?id=546857#c245
comments in there myself - in fact I was one of the people pushing for
a whitelist add-on so that us remote XUL developers wouldn't be left
_completely_ without a platform for our existing products.
While the add-on is okay as a solution for some of our customers, many
have a corporate policy that prohibits the use of Firefox for one
reason or another. For example one huge multinational that we work
with - a brand name that everyone will be familiar with - has a policy
of only using IE6 (!!!) as their web browser. I guess they've got too
many legacy intranet apps to switch. No matter how hard we try, we'll
never sell them a product that works in Firefox, but we _can_ sell it
as "requiring a XUL runtime environment, such as Prism, to be
installed".
They're the biggest company with that restriction, but are by no means
the only one.
> Regarding "remote XUL" support in chromeless, no.
* No we won't actively support it, but if it happens to work then good
luck to you
* No, we'll be taking specific steps to stop it working
* No, we'll be taking specific steps to stop it working, but there
might be some option, like the whitelist extension for Firefox, to
allow it to be re-enabled.
> I'm sorry recent decisions have affected you like this. I hope the
> whitelist workaround helps ease your pain, and from my side would be
> willing to support and contribute to a simple user facing version of
> prism on top of chromeless.
this project, we're not able to simply rework it in HTML in a short
space of time. Not to mention the fact that HTML still lacks a few
niceties of XUL which makes such a transition even more difficult.
With the writing clearly on the wall for remote XUL - and in the long
term I would imagine for local XUL as well - we will be transitioning
it to HTML at some point, but obviously have to continue to sell our
existing product in the meantime.
It looks increasingly like our only recourse will be to roll our own
XULRunner-based client for our app, which is something we were trying
to avoid as it puts us in the firing line for security updates and so
on.
Many thanks for your answers though, at least I have a better idea
where we stand, even if that is on somewhat shakey ground.
Mark
enefekt
It will be based on "XULRunner" after all, and the bits and XUL
runtime and toolkit will be already bundled.
So why add more KB for a JavaScript UI library when an awesome one
already comes bundled.
EricG
additional functionality through an API to make Chromeless more on par
with say "Adobe AIR" where we can access filesystem and other things,
then I think Chromeless would definitely be a better direction. I
think a environment where we have full control over Native Menu's and
Dialog boxes would be awesome, giving our application a more desktop
style interface to boot.
That's the advantages I can see with Chromeless, give web applications
the same capabilities of desktop applications in a native environment.
I'd like to see:
Native Menus
Native Dialog Boxes
Access to the File System
Full Screen Control
Native Options for Windows, Modal, Dialog, Toolbar, etc.
Maybe a mobile edition that allows for "native" mobile apps, like
PhoneGap
MarkC
> I think if Chromeless get's the same functionality of Prism, and
> additional functionality through an API to make Chromeless more on par
> with say "Adobe AIR" where we can access filesystem and other things,
few years ago, when security wasn't such a major concern, remote XUL
apps could easily request elevated privileges to allow access to the
file system, native dialogues and alerts, modal windows and so on.
Even now remote XUL provides native menus, toolbars and other widgets,
all in a language that is far more consistent than HTML, and far
better suited to UI design. And yet it's now being suppressed, and
will undoubtedly go away at some point, because it doesn't constitute
part of "the open web". Until there are APIs for these features which
are agreed at the W3C/WHATWG level, I don't see Mozilla wanting to
invest development resources in reimplementing their existing non-
standard code in yet another non-standard manner.
I'd love to see this level of integration officially supported in some
way. Until then HTML will continue to be a complex mess of a document
markup language shoehorned into the application space - much like a
Word document with macros. I just hope that kind of integration
becomes available before they switch off the life support for remote
XUL and leave us with no other options.
Lloyd Hilaiel
Here's current progress on the features you mention:
On Mon, Feb 07, 2011 at 04:39:23PM -0800, EricG wrote:
> I'd like to see:
> Native Menus
First cut complete in a couple days, stay tuned (Mike De Boer's
done a lot of work for this feature, and awaits merge):
https://github.com/mozilla/chromeless/issues#issue/39
> Native Dialog Boxes
Haven't even looked at this feature yet, there are some things to
think through here. I imagine a postMessage like api for
communicating with spawned dialogs might work fine. I see below you
suggest three different window types, that sounds reasonable.
Marcio has opened a bug to track this one:
https://github.com/mozilla/chromeless/issues#issue/43
> Access to the File System
First cut avaiable now. See these apis for details:
+ http://mozilla.github.com/chromeless/#module/api-utils/file
+ http://mozilla.github.com/chromeless/#module/chromeless-kit/app-paths
> Full Screen Control
done: http://mozilla.github.com/chromeless/#module/chromeless-kit/fullscreen
> Native Options for Windows, Modal, Dialog, Toolbar, etc.
> Maybe a mobile edition that allows for "native" mobile apps, like
> PhoneGap
Mobile does sound interesting. No explicit existing work in this
direction, but I think all that has to happen is to figure out a clean
way to partition device specific apis (not all desktop apis will be
meaningful on mobile), to get builds of xulrunner for the targeted
devices, and to go.
I'm personally interested in focusing on the desktop case to start, but given
that chromeless is built on code that targets mobile anyway, I don't feel like
this would be a massive amount of work.
best,
lloyd
David Fraser
> While the add-on is okay as a solution for some of our customers, many
> have a corporate policy that prohibits the use of Firefox for one
> reason or another. For example one huge multinational that we work
> with - a brand name that everyone will be familiar with - has a policy
> of only using IE6 (!!!) as their web browser. I guess they've got too
> many legacy intranet apps to switch. No matter how hard we try, we'll
> never sell them a product that works in Firefox, but we _can_ sell it
> as "requiring a XUL runtime environment, such as Prism, to be
> installed".
>
> They're the biggest company with that restriction, but are by no means
> the only one.
>
still have older versions of IE, and whose web policy prevents them
from installing another browser, Prism was great - we just had to
bundle it up in an installer with a link to the App.
Now we have Chromeless, which it sounds like we could build the same
thing out of (although it would be more work?), and also the new
WebRunner, both aiming to take it's place. So "Prism is now WebRunner"
and "Prism is now Chromeless": You light your lantern and step warily
into the blackness. Cobwebs brush your face and you hear the scurrying
of tiny feet: rats, most likely. You set off into the cave. After a
few yards you arrive at a junction. Will you turn west (turn to 71) or
east (turn to 278)?
David