I have tried to mess with xulrunner before, and now I'm trying once again :)
The "real" tutorial (Getting started with XULRunner - MDN) does, in fact, show that one is supposed to have application.ini and other files (possibly zipped as .xpi, which then requires --install-app ...), and then the call should be like:
xulrunner `pwd`/application.ini
... however, I'd like an easier way to start up - and hence, my hope for single-file XUL application approach :) (A good note here is that one also cannot use the zipped .xpi as an argument to xulrunner, see XULRunner question - DonationCoder.com)
The thing is, I am almost 100% certain that at some point in the past, I have used a simple single-file XUL application, as in (pseudocode):
xulrunner my-xul-app.extension
... but I cannot remember how it went :) So, was that possible with xulrunner, or only with firefox?
As far as I can remember, I used something like a 'my-xul-app.xul' file (as the single-file application), which would specify only, say, a window with a single button (that couldn't really do anything due to lack of javascript) - and I'd like to repeat the same thing now, to refresh my memory (unless I confused something from back then :))
First of all, I found HOWTO: Getting Started with Linux Standalone Apps using XUL - Ubuntu Forums (2007), and I modified the example.xul file used there as:
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window
id = "myapp"
title = "SQLite Example"
height = "420"
minHeight = "420"
width = "640"
minWidth = "640"
screenX = "10"
screenY = "10"
sizemode = "normal"
xmlns = "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" >
<spacer style = "height: 4px; cursor: default;" />
</window>
and I'm trying to "run" this as recommended in link, with:
firefox -no-remote -chrome file:$PWD/example.xul
... and what happens is that Firefox opens, with window size being like 1x1 pixels; if you can find the handle, you can stretch the window, and read:
Remote XUL
This page uses an unsupported technology that is no longer available by default in Firefox.
Ouch :( Answers to this (like How do I fix the Remote XUL error I get when using Firefox 4.x and the Webmail Advanced Interface?) seem to be related to actual remote xul (and recommend a plugin to handle that); but what I want is simply to run a file locally?! Where did the "remote" part come from?
Also, seeing the firefox switch '-app' (Using Firefox 3 as a XUL runtime environment); although it refers to an application.ini, I tried this:
firefox -no-remote -app $PWD/example.xul
... and Firefox just started as usual.
Btw, I cannot see neither -app nor -chrome command line options in firefox --help ;)
But actually, I do not really want to use firefox as an engine - just the xulrunner; and I tried the Firefox approach because I thought it is more-less the same as xulrunner; turns out it isn't (even if you use application.ini: Why does 'firefox -App application.ini' and 'xulrunner application.ini' behave differentely? | Firefox Support Forum):
In any case, if I run just xulrunner (as I wanted to), I get:
$ xulrunner example.xul
Error: App:Name not specified in application.ini
So, I can see everything points to "single source file" app not being possible with xulrunner - but I just wanted to make sure (in case I missed some obscure tutorial :) ). And if it isn't - does anyone remember if it was possible at a previous point in time?
PS:
$ firefox --version
Mozilla Firefox 7.0.1
$ xulrunner --version
Mozilla XULRunner 2.0 - 20110402003021
$ uname -r
2.6.38-11-generic
$ cat /etc/issue
Ubuntu 11.04 \n \l
I don't believe you could ever create single-file XULRunner applications. The -chrome <...> parameter probably used to work, I guess the "Remote XUL" error comes from the fact that the URL is file://, not chrome://.
You could use something like the Live XUL Editor in the Developer Assistant (formerly Extension Developer's extension) to test XUL quickly.
The general idea I hear these days is that you should write HTML5 instead, whenever you can, since it is more actively developed, more well-known technology with less incompatible changes and better tooling...
Here is the answer I wrote for another related question, reproduced here because it may help someone who want to know how to package their XUL application.
It is too bad that xulrunner can not run a zipped .xpi or .xulapp directly, but it is possible to package most of your .js, .xul, .css and .png files into a jar and wrap everything up with a private copy of xulrunner, without having to run --install-app
These are the steps I went through to package our XUL application.
The first step is to put all your files (except application.ini, chrome.manifest, and prefs.js) into a .jar file like this (all of this was carried out under Windows, make appropriate adjustments for Linux and OSX)
zip -r d:\download\space\akenispace.jar * -i *.js *.css *.png *.xul *.dtd
Then in d:\download\space, layout your files as follows:
D:\download\space\akenispace.jar
D:\download\space\application.ini
D:\download\space\chrome.manifest
D:\download\space\defaults
D:\download\space\defaults\preferences
D:\download\space\defaults\preferences\prefs.js
The content of the files are as follows
application.ini
[App]
Vendor=Akeni.Technologies
Name=Akeni.Space
Version=1.2.3
BuildID=20150125
Copyright=Copyright (c) 2015
ID=space#akeni.com
[Gecko]
MinVersion=1.8
MaxVersion=35
chrome.manifest
content akenispace jar:akenispace.jar!/chrome/content/
skin akenispace default jar:akenispace.jar!/chrome/skin/
locale akenispace en-US jar:akenispace.jar!/chrome/locale/en-US/
resource akenispace jar:akenispace.jar!/chrome/resource/
prefs.js
pref("toolkit.defaultChromeURI", "chrome://akenispace/content/space.xul");
Now you can put these files into your .wxs for WiX and produce an MSI file for Wndows.
Of course you need to include all the files for XULRunner as well.
Related
I am required to make a custom FireFox profile on a RHEL based system.
most of the configuration are changed inside the FireFox inside the about:config menu.
When I try and lock parameter values using the "mozilla.cfg" file and the "lockPref("", )" function the browser doesn't seem to read those files, I place the file both in: "~/.mozilla/firefox/" and "/usr/lib64/firefox/". I used the http://kb.mozillazine.org/Lock_Prefs guide and some more and still I have no one answer about where those function should be written and how do I check that those functions were loaded.
I would like some clear instructions or a definitive guide that I just couldn't manage to find.
Thanks!
This came up fairly high in a Google search when I was asking the same question, but did not have an answer at the time.
I found the following reference:
https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment
On RHEL7, the files needed to be added to the following locations:
/usr/lib64/firefox/defaults/preferences/autoconfig.js (root:root, 644)
/usr/lib64/firefox/mozilla.cfg (root:root, 644)
Is this the only SO question about listing drives ??
I'm on Windows, I'm a newbee in addon developement, I (currently) use Firefox Addon SDK with Node.js/jpm, but not Web Extensions (yet), nor the XPCOM/XUL thing. Seems like some are mixing the whole thing..
Correct me if I'm wrong, but as of May 2016, Web Extensions can't parse File System (otherwise I would be very happy to have access to the documentation allowing that too ^^.) And it appears that the Require chrome is now deprecated along with XUL/XPCOM things. As I guess everyone is pushed forward (looks like) to go Web Extensions (that is out of the scope of the subject), there's no way I would go Require chrome as I would have to drop it anyway next year...
So how do we list drives in Firefox Addon SDK without importing the deprecated libraries ?
My answer below, but would like to have a better option if any. The MDN page about is :
either talking about deprecated methods
or just showing you how to manipulate a directory you already know the whereabout.
Here is what I could do with the Addon SDK (or initially jetpack if I'm not mistaken), and yeah, that's a kind of hack because I don't know how to do it in a cleaner way, and I don't want to use Require Chrome.
Minimal version :
// index.js or main.js
// declare the io/file API :
var ioFile = require('sdk/io/file');
// array to make attempts :
let drivesIds = ["c", "d", "e", "f", "g", .... "z" ]; // hack isn't it ? :/
for (let i = 0; i < drivesIds.length; i++) {
let driveName = drivesIds[i] + ":\\";
if (ioFile.exists(driveName)) {
console.log(driveName + " is a drive and is ready !");
}
}
And you're done ! Okay, that was pretty obvious, but I failed to find that code anywhere I searched, or a code that does it better (again, without require('chrome'))
Extended versions can :
put the whole thing in a function getDrives() that returns array of drives objects like { path: "c:\\", hasChildren: true, etc: "etc" }. (check for child directories by combining ioFile.isFile() with ioFile.list() in a for loop that breaks the moment a subdir is encountered.
port the code to another addon module, with exports implementations
even encapsulates io functions and properties as members of a global object in a module (you can monitor filesystem changes like unplugged dir, store filesystem tree in memory, etc.)
All that making your index.js file lighter. Can this be adapted to other OS ? I don't know. The title is misleading while this is the only question about listing drives Addon SDK tagged.
Never ever try to build an entire drive tree, that would bring the computer to a halt, and fail at a point or another because io/file is limited to 250-260 chars in path length on Windows.
Security issues ! That's probably why it's undocumented, why WebExtensions disallows io operations ? But, I use that to inject a nice windows explorer (select a dir to save whatever you want in there, shortcutting save as or download dialogs). That's the only relevant reason why I use Firefox. I would go back to dotNet and reinvent the wheel with again lots of security holes if io is not flexible enough (or missing) in WE, or try Chrome instead (if no deprecated API in the next 10 years). Fact is, the moment you can automate io parsing, there will be security issues, but the moment you disallow that, Addon extensions is not the way to go with filesystem.
I've been trying for hours, but can't build and use Light Table. Every time I try to run deploy/LightTable, it hangs on a screen that simply says "Light Table". I receive this error*:
[14381:0519/204037:INFO:CONSOLE(27860)] "Uncaught TypeError: Cannot read property 'thread_STAR_' of undefined", source: file:///home/zaz/Desktop/LightTable/builds/lighttable-0.8.0-linux/resources/app/core/node_modules/lighttable/bootstrap.js (27860)
Here's what I've tried:
git clone https://github.com/LightTable/LightTable.git
cd LightTable
bash linux_deps.sh
./deploy/LightTable # creates frozen window, throws the error above
cd deploy
./LightTable # creates frozen window, throws the error above
./ltbin # creates frozen window, throws the error above
I also tried similar things after checking out the atom-shell branch and the 0.7.2 tag (and cleaning up all the files from the previous build). Each time, I received the error above.
Does anyone know what's going on here?
Has Light Table been completely abandoned? It seems the last commit was in March.
* Depending on the version I was trying to run, I also received other errors, but I don't think they're relevant (the error above was the only one that appeared for all versions):
[18593:0519/222845:INFO:gpu_info_collector_x11.cc(80)] NVCtrl extension does not exist.
[18593:0519/222845:ERROR:browser_main_loop.cc(226)] Gdk: gdk_window_set_icon_list: icons too large
Fontconfig warning: FcPattern object size does not accept value 11(i)
[14413:0519/204035:INFO:renderer_main.cc(212)] Renderer process started
A year later (question was written in May 2015, now is June 2016), LightTable 0.8.1 is out, and I tried both Linux binary and cloned it from git, and it works fine.
For complete info, I'm using also Atom, and although I had not problems with "Cannot read property 'something' of undefined"" in Atom core, I met such problems in two or three Atom packages.
Both editors are based on same electron platform, LightTable is beautiful eye candy with quite revolutionary REPL integration, but it needs more polish to be usable to same extent as Atom.
For example, LightTable does not have workspace saving by default, that is done via plugin. That's ridiculous.
But although Atom looks so nice and powerful compared to simple editors, with realy huuuge number of available packages/plugins, LightTable is more elegant.
As I don't want to start new semi-religious war Atom vs LightTable resembling vi-vs-emacs, I'll stop here. :)
I can't replicate your problems in LightTable v0.8.1, so I think that answers this question. If not, please add errors you get with v0.8.1.
For info about releases, please check: https://github.com/LightTable/LightTable/releases
I have installed RedHawk 1.10.0 using Ubuntu 14.0.4LTS as described in appendix F of the RedHawk documentation. I also installed standalone IDE from SourceForge
again, as specified in appendix F, chapter 2.5. The IDE comes up looking ok, but here are the problems:
The components list is empty (there are supposed to be a set of pre-defined components). The directory is empty as well on the file system.
When attempting to generate C++ component, I get:
"Exception running "/bin/redhawk-codegen" /bin/redhawk-codegen - template=redhawk.codegen.jinja.cpp.component.pull --checkSupport
In detail, it said: bin/redhawk-codegen":error=2 no such file or directory. The /bin/redhawk-codegen is there under OSSIEHOME. The "pull" template is under: /usr/local/lib/python2.7/dist-packages/redhawk/codegen/jinja/cpp/component.
If I attempt to start Domain Manager I get an error "no domain configuration available".
So for all these problems it is obvious that I need to get a better picture of the expected file layout of all IDE and core RedHawk components. This is not clear from the documentation. Is there a starting point where I can begin debugging "where to find things"?
Regarding your first issue:
When installing for CentOS using the RPMs, a number of components, and devices are pre-packaged into the yum repository. When installing from source, as one must do for Ubuntu in 1.10, the pieces of Redhawk are modular and are installed individually.
The directions from Appendix F walk the user through installing each of the parts that make up the framework. The core, a GPP, bulkio, bustio, and the code generator. This does not include any components or devices (other than the GPP). To install these, you'll need to clone them from their respective git repositories and build and install from source either from the command line, or through the REDHAWK IDE. Building and installing the components from the command line follows the same pattern as the framework, there is a reconf script, which creates the configure script which creates the makefile script. eg. ./reconf; ./configure; make; sudo make install
Regarding your second issue:
These symptoms seem to point to the OSSIEHOME and SDRROOT variables not being set. Make sure that the OSSIEHOME and SDRROOT variables are set in the terminal using "echo $SDRROOT" and "echo $OSSIEHOME" prior to running the IDE. Keep in mind that the environments are unique to each session so, for example, having them set in one bash terminal does not guarantee they are set when launching the IDE from a desktop shortcut. Confirm they are set in your terminal, then launch the IDE from the same terminal.
Regarding your last issue:
This is likely also caused by your second issue. However, if it is not resolved following the above steps, take a look within $SDRROOT/dom/domain There should be two files. One DomainManager.dmd.xml.template and one DomainManager.dmd.xml. If all you have is the template then you need to create the DomainManager.dmd.xml file by copying the template. Then edit it and fill in the id and name fields. The default name is generally REDHAWK_DEV and the id should be a UUID.
I am writing a small command line utility. It should hopefully be able to run on OSX, UNIX and Linux.
It needs to save a few preferences somewhere, like in a small YAML config file.
Where would one save such a file?
Language: Python 2.7
OS: *nix
Commonly, these files go somewhere like ~/.rc (eg: ~/.hgrc). This could be the path to a file, or to a directory if you need lots of configuration settings.
For a nice description see http://www.linuxtopia.org/online_books/programming_books/art_of_unix_programming/ch10s03.html
I would avoid putting the file in the ~ directory only because it has gotten totally flooded with crap. The recent trend, at least on ubuntu, is to use ~/.config/<appname>/ for whatever dot files you need. I really like that convention.
If your application is named "someapp" you save the configuration in a file such as $HOME/.someapp. You can give the config file an extension if you like. If you think your app may have more than one config file you can use the directory $HOME/.someapp and create regular-named (not hidden) files in there.
Many cross-platform tools use the same path on OS X as on linux (and other POSIX/non-Windows platforms). The main advantage of using the POSIX locations isn't saving a few lines of code, but saving the need for Mac-specific instructions, and allowing Mac users to get help from the linux users in the community (without any need to translate their suggestions).
The other alternative is to put them in the "Mac-friendly" locations under ~/Library instead. The main advantage of using the Mac locations is basically "Apple says so"—unless you plan to sandbox your code, in which case the main advantage is that you can do so.
If you choose to use the Library locations, you should read About the OS X File System and OS X Library Directory Details in the File System Programming Guide, but here's the short version:
Almost everything: Create a subdirectory with your app's name or bundle ID (unless you're going out of your way to set a bundle ID, you'll get org.python.python, which you don't want…) under ~/Library/Application Support. Ideally you should use APIs like -[NSFileManager URLForDirectory:inDomain:appropriateForURL:create:error:] to get the path; if not, you have to deal with things like localization, sandbox containers, etc. manually.
Anything that can be easily re-created (so it doesn't need to be backed up, migrated, etc.): An identically-named subdirectory of ~/Library/Caches.
Preferences: Use the NSUserDefaults or CFPreferences APIs instead. If you use your own format, the "old" way of doing things is to create a subdirectory under ~/Library/Preferences named with your app's name or bundle ID, and put your files in that. Apple no longer recommends that, but doesn't really recommend an alternative (short of "use CFPreferences, damnit!"); many apps (e.g., Aquamacs) still do it the old way, but others instead pretend they're not preferences and store them under Application Support.
In Python, this works as follows (leaving out the error handling, and assuming you're going by name instead of setting a bundle ID for yourself):
from Foundation import *
fm = NSFileManager.defaultManager()
appsupport = (fm.URLForDirectory_inDomain_appropriateForURL_create_error_(
NSApplicationSupportDirectory, NSUserDomainMask, None, True, None)[0].
URLByAppendingPathComponent_isDirectory_(
appname, True))
caches = (fm.URLForDirectory_inDomain_appropriateForURL_create_error_(
NSCachesDirectory, NSUserDomainMask, None, True, None)[0].
URLByAppendingPathComponent_isDirectory_(
appname, True))
prefs = NSUserDefaults.persistentDomainForName_(appname)