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
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
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.
Cool! Do you have posted your ideas anywhere?
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
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