Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
XULRunner on OS X, Why is not supported?
122 views
Skip to first unread message
richardso...@gmail.com
Nov 6, 2012, 4:58:39 PM11/6/12
to
At first I tried for a couple of days to try to get xulrunner 16.0.2 to work on my OSX 10.6, until I understoo it wasn't working at all running the 'xulrunner -v' will return an 'error' string where the version should come out.
Looking in forums such as this I found out it is a well known error, that there is actually a bug reported from last year about it, which does not have anybody working on it.
So I changed my focus to 'Macports' they have two packages available where only 'xulrunner-devel' which is at version 2.0, actually worked. I got in contact with the previous maintainer and he dropped the support for the package 9 months ago because it was taking too much of his time to maintain the package, he said that he kept battling with the code making bug reports to get each version to work on OS X. Well enough, I got to an understanding that the platform is supported primarly to have FF or TB be able to work on OSX, were this project have their own maintainers, for what I'm seeing it is my deduction that the mac compilation is being done automatically and nobody is actually taking the time to try it out on OS X platform.
By making post I would like to raise concern about this, probably the use of xulrunner on OS X is not very popular I would say that nobody has asked for this before. I could surely go about and start taking care of this myself, although I would like to get more acquainted with the platform to understand more the parts of it. Currently I've developed an extension and now I'm going to start my first application which I'm kind of stuck using version 2.0 of the platform.
I'm not sure if I'm really the only one with this issue, but surely I would like to hear from anyone else if they themselves would like to see xulrunner be more compatible with OS X, and if can't be more compatible why is that to see if any of us can help.
Looking in forums such as this I found out it is a well known error, that there is actually a bug reported from last year about it, which does not have anybody working on it.
So I changed my focus to 'Macports' they have two packages available where only 'xulrunner-devel' which is at version 2.0, actually worked. I got in contact with the previous maintainer and he dropped the support for the package 9 months ago because it was taking too much of his time to maintain the package, he said that he kept battling with the code making bug reports to get each version to work on OS X. Well enough, I got to an understanding that the platform is supported primarly to have FF or TB be able to work on OSX, were this project have their own maintainers, for what I'm seeing it is my deduction that the mac compilation is being done automatically and nobody is actually taking the time to try it out on OS X platform.
By making post I would like to raise concern about this, probably the use of xulrunner on OS X is not very popular I would say that nobody has asked for this before. I could surely go about and start taking care of this myself, although I would like to get more acquainted with the platform to understand more the parts of it. Currently I've developed an extension and now I'm going to start my first application which I'm kind of stuck using version 2.0 of the platform.
I'm not sure if I'm really the only one with this issue, but surely I would like to hear from anyone else if they themselves would like to see xulrunner be more compatible with OS X, and if can't be more compatible why is that to see if any of us can help.
passfree
Nov 7, 2012, 12:09:35 PM11/7/12
to
Hi Richard,
I would love to get more support for xulrunner given that I have already spent 3 year on xulrunner-based application but I am getting none. My advice is to stay away from it. It is clear that Mozilla is not taking this product anywhere. If you like to do stuff in Markup and Javascript than stick to HTML and create your own wrapper with Webkit because Gecko is really hard to use. Do the native stuff natively and the main interface in HTML, JavaScript and CSS. It works. Moreover, fiddling with XPCOM is not worth the effort - I am talking from personal experience. You may as well implement stuff natively instead of spending countless of hours tracing weird bugs.
I would love to get more support for xulrunner given that I have already spent 3 year on xulrunner-based application but I am getting none. My advice is to stay away from it. It is clear that Mozilla is not taking this product anywhere. If you like to do stuff in Markup and Javascript than stick to HTML and create your own wrapper with Webkit because Gecko is really hard to use. Do the native stuff natively and the main interface in HTML, JavaScript and CSS. It works. Moreover, fiddling with XPCOM is not worth the effort - I am talking from personal experience. You may as well implement stuff natively instead of spending countless of hours tracing weird bugs.
Dave Townsend
Nov 7, 2012, 2:28:44 PM11/7/12
to
On 11/06/12 13:58, richardso...@gmail.com wrote:
> At first I tried for a couple of days to try to get xulrunner 16.0.2 to work on my OSX 10.6, until I understoo it wasn't working at all running the 'xulrunner -v' will return an 'error' string where the version should come out.
>
> Looking in forums such as this I found out it is a well known error, that there is actually a bug reported from last year about it, which does not have anybody working on it.
Can you let us know what the bug number was? We still try to keep
> At first I tried for a couple of days to try to get xulrunner 16.0.2 to work on my OSX 10.6, until I understoo it wasn't working at all running the 'xulrunner -v' will return an 'error' string where the version should come out.
>
> Looking in forums such as this I found out it is a well known error, that there is actually a bug reported from last year about it, which does not have anybody working on it.
XULRunner working on all platforms and I hadn't heard that there were
any problems on OSX recently.
Long term it should be said that Mozilla isn't committed to supporting
XULRunner. At some point if the work required to keep it working is too
much it will likely be dropped permanently. For now we try to keep an
eye on it and fix problems as they arise which is thankfully rare.
richardso...@gmail.com
Nov 8, 2012, 1:41:30 PM11/8/12
to
richardso...@gmail.com
Nov 8, 2012, 2:06:52 PM11/8/12
to
I believe my question is, if Mozilla is taking out their app development platform not 'XUL' per se. How would they promote "openness, innovation and opportunity on the web", only by giving us the opportunity of doing so in extensions on a browser?
What's the strategy? Is not clear where is this going?
What's the strategy? Is not clear where is this going?
Ted Mielczarek
Nov 8, 2012, 2:34:25 PM11/8/12
to dev-pl...@lists.mozilla.org
On 11/8/2012 2:06 PM, richardso...@gmail.com wrote:
> I believe my question is, if Mozilla is taking out their app development platform not 'XUL' per se. How would they promote "openness, innovation and opportunity on the web", only by giving us the opportunity of doing so in extensions on a browser?
>
> What's the strategy? Is not clear where is this going?
How is "on the web" not clear? Our mission is to promote the growth of
> I believe my question is, if Mozilla is taking out their app development platform not 'XUL' per se. How would they promote "openness, innovation and opportunity on the web", only by giving us the opportunity of doing so in extensions on a browser?
>
> What's the strategy? Is not clear where is this going?
the web, not native desktop applications. XUL is simply a means to an
end that we use to produce Firefox. Promoting XUL does not help the web.
XULRunner is an artifact of the process we use to build Firefox. It's
never been officially supported, but we continue to release builds
because people find them useful. If you're looking for a well-supported
framework for building general desktop apps you should look elsewhere.
-Ted
richardso...@gmail.com
Nov 8, 2012, 3:46:42 PM11/8/12
to dev-pl...@lists.mozilla.org
I was just reading the effort of installing "open web apps" locally, I'm assuming the strategy shift that I'm talking about is that Mozilla is betting on Firefox as their application framework, that would make sense not to support Xulrunner anymore.
I would like to see how could one use the native stuff like platform specific stuff (Cocoa for example) on this "open web apps". Don't get me wrong I love Web technologies but an HTML TAB is never going to feel the same as the OS Native TAB.
Xulrunner gives that bridge of developing in the Web technologies, with multiplatform capabilities and still make use of the native stuff. A lot of nice applications are still being developed with xulrunner. Still having your own executable you are still able to distribute your application in a different manner than using the web.
Dave Townsend
Nov 8, 2012, 8:38:44 PM11/8/12
to
On 11/08/12 12:46, richardso...@gmail.com wrote:
>
> I was just reading the effort of installing "open web apps" locally, I'm assuming the strategy shift that I'm talking about is that Mozilla is betting on Firefox as their application framework, that would make sense not to support Xulrunner anymore.
>
> I would like to see how could one use the native stuff like platform specific stuff (Cocoa for example) on this "open web apps". Don't get me wrong I love Web technologies but an HTML TAB is never going to feel the same as the OS Native TAB.
I guess it depends specifically what platform specific stuff you're
>
> I was just reading the effort of installing "open web apps" locally, I'm assuming the strategy shift that I'm talking about is that Mozilla is betting on Firefox as their application framework, that would make sense not to support Xulrunner anymore.
>
> I would like to see how could one use the native stuff like platform specific stuff (Cocoa for example) on this "open web apps". Don't get me wrong I love Web technologies but an HTML TAB is never going to feel the same as the OS Native TAB.
talking about, but we are betting on the web, and where the web doesn't
give you enough then extending the web by defining standards and
supports for more capabilities. See for example all the APIs that are
being developed in the B2G project.
Robert Kaiser
Nov 9, 2012, 7:57:16 AM11/9/12
to
richardso...@gmail.com schrieb:
in 1998 that what they would really want to do, using HTML as the
technology to build UI, was not there yet. Nowadays we are getting
closer and closer to being there, and developing Firefox OS and the
needed APIs for all kinds of apps there is one further step on this way.
We sincerely hope that HTML and friends can obsolete XUL in the next few
years.
If you try to use our technology for a new project today, I'd urge you
to try to get as far as possible with HTML, and try to work with us to
bring those pieces to HTML stack that it cannot do today but XUL can.
Not everything will be feasible in the same way on the web, but we want
web apps to become as powerful as native apps in the long run. And in
the mean time, you can use XULRunner underneath your HTML app and fill
in the gaps with XUL/XPCOM technology, until we're able to fill them
with HTML and actual web APIs.
Robert Kaiser
> I believe my question is, if Mozilla is taking out their app development platform not 'XUL' per se. How would they promote "openness, innovation and opportunity on the web", only by giving us the opportunity of doing so in extensions on a browser?
>
> What's the strategy? Is not clear where is this going?
XUL was always only a transitional technology as the project discovered
>
> What's the strategy? Is not clear where is this going?
in 1998 that what they would really want to do, using HTML as the
technology to build UI, was not there yet. Nowadays we are getting
closer and closer to being there, and developing Firefox OS and the
needed APIs for all kinds of apps there is one further step on this way.
We sincerely hope that HTML and friends can obsolete XUL in the next few
years.
If you try to use our technology for a new project today, I'd urge you
to try to get as far as possible with HTML, and try to work with us to
bring those pieces to HTML stack that it cannot do today but XUL can.
Not everything will be feasible in the same way on the web, but we want
web apps to become as powerful as native apps in the long run. And in
the mean time, you can use XULRunner underneath your HTML app and fill
in the gaps with XUL/XPCOM technology, until we're able to fill them
with HTML and actual web APIs.
Robert Kaiser
richardso...@gmail.com
Nov 8, 2012, 3:46:42 PM11/8/12
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org
I was just reading the effort of installing "open web apps" locally, I'm assuming the strategy shift that I'm talking about is that Mozilla is betting on Firefox as their application framework, that would make sense not to support Xulrunner anymore.
I would like to see how could one use the native stuff like platform specific stuff (Cocoa for example) on this "open web apps". Don't get me wrong I love Web technologies but an HTML TAB is never going to feel the same as the OS Native TAB.
Simon Kornblith
Nov 12, 2012, 2:22:13 PM11/12/12
to
On Nov 8, 3:46 pm, richardson.balca...@gmail.com wrote:
> I was just reading the effort of installing "open web apps" locally, I'm assuming the strategy shift that I'm talking about is that Mozilla is betting on Firefox as their application framework, that would make sense not to support Xulrunner anymore.
>
> I would like to see how could one use the native stuff like platform specific stuff (Cocoa for example) on this "open web apps". Don't get me wrong I love Web technologies but an HTML TAB is never going to feel the same as the OS Native TAB.
If by TAB you mean the UI element (and not the soft drink, or
> I was just reading the effort of installing "open web apps" locally, I'm assuming the strategy shift that I'm talking about is that Mozilla is betting on Firefox as their application framework, that would make sense not to support Xulrunner anymore.
>
> I would like to see how could one use the native stuff like platform specific stuff (Cocoa for example) on this "open web apps". Don't get me wrong I love Web technologies but an HTML TAB is never going to feel the same as the OS Native TAB.
something else), then I think it's worth pointing out that, on OS X,
the tabs in your Firefox window aren't native. They are XUL stylized
to look like native tabs (CSS at
https://mxr.mozilla.org/mozilla-central/source/browser/themes/pinstripe/browser.css#2113).
There's nothing preventing you from stylizing HTML the same way.
Simon
passfree
Nov 13, 2012, 11:04:59 AM11/13/12
to
btw,
To some extend it will be possible to create a XUL port in HTML via some CSS trickery. I also hope that XBL/XBL2 picks up to simplify this process even further. However, we are talking about some serious commitment here because it is a lot of work.
To some extend it will be possible to create a XUL port in HTML via some CSS trickery. I also hope that XBL/XBL2 picks up to simplify this process even further. However, we are talking about some serious commitment here because it is a lot of work.
0 new messages