This could be the motivation I need to move to Chrome for development. Working on an application with PouchDB (syncing with a CouchDB instance). I see everywhere that there are links to a Firefox add-on called PouchDB-Inspector which is meant to join the developer tools arsenal. True for Chrome - which does install and work. Firefox - the link is dead - Not found.
https://addons.mozilla.org/firefox/addon/pouchdb-inspector/
Does anyone know where it is? Is it discontinued? Done with? Never to be found again?
Any help would be great? Thanks.
This add-on seems to be currently unavailable from addons.mozilla.org, but you can get it from it's github project page. The creator also provides a link to the current xpi file that you can install manually.
My goal is call a Windows Service, passing a string as parameter, from a google chrome extension.
Is it possible? Any samples available?
I did the same question on Codeproject and the user kbrandwijk has solved my problem.
Here is his answer. I'm posting here to help anyone who have the same question.
The only part of the API that allows you to communicate outside of the sandbox since NPAPI is phased out, is the Native Messenging API. This approach would however, require you to install a host and register it in Chrome.
This host can be a small C# program that actually talks to the Windows Service. Check the example here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/api/nativeMessaging/
I am new in Plugin development.I heard from blog that Chrome is going to stop support on NPAPI plugins.I developed one native application in Mac, i am trying to make it as a plugin. But i didn't find a perfect tutorial that how the native application and plugin will interact. I gone through the chrome developers page, but its only gave some basic idea about the message passing. But for a new developer it is quite difficult to understand. Please help me in this. It would be great
I am trying to start development in Objective-J but I am completely lost as to how to set it up. The documentation about setting it up, didn't really help me. I am very familiar with web development and Objective-C so I can write the programs if I can get everything set up. Could somebody please give me step-by-step directions as to how to set it up on my (shared) server?
This little "tutorial" didn't help me out at all.
Go to the Cappuccino download page and download the starter package. Unzip it into a folder your choice. Congratulations, you now have your first Cappuccino app ready to run! If you are using Safari you can open up index-debug.html right away and start trying out the starter app. (If you use other browsers like Chrome and Firefox they might not allow you to run a web app from a file:// URL. Instead you'll need to start up a web server and surf to the index-debug.html file through the server.)
Then you can start to edit the sample application right away and explore.
Once you are ready to learn more, take a look at these Cappuccino tutorials and instructions. They are still under development - we're not quite there with our new site yet - but they are definitely more up to date.
How can I use the browser as a UI for a desktop app? The ways I have come up with so far are...
Use all HTML/Javascript. Problem: Can't access filesystem or just about anything else.
Run a local webserver while the application is in use. Problem: How do I kill it when the user is done? My users are not technical enough to Ctrl+C.
Embed a browser component in a regular GUI. Problem: Embedded browser components tend to be glitchy at best. The support for Javascript/CSS is never as good as it is in a real browser.
...?
The ideal solution would work with any technology. I know there are options like writing Firefox extensions, but I want to have complete freedom in the backend technology and browser independence.
Please note that if you choose to run a local webserver, you're creating a security risk.
Any webpage running on the same machine that knows about your app can send requests to your server using Javascript, and you have no simple and reliable way of knowing what the request came from. (Don't trust the referer header)
Google Desktop, which uses a similar approach, has had several real-world vulnerabilities that allow any webpage to read any file on disk.
There are several ways to protect against this; I would recommend requiring each request to have a auth key which is randomly generated per-machine (and expires at some point), which you could put in the source for the actual pages. XHR protection would prevent malicious websites from reading the auth key, rendering them powerless.
If you are looking for a python Web Server with a Kill link, you could always check CherryPy.
import webbrowser
import cherrypy
import threading
class MyApp:
""" Sample request handler class. """
#cherrypy.expose
def index(self):
return """<html><head><title>An example application</title></head>
<body>
<h1>This is my sample application</h1>
Put the content here...
<hr>
Quit
</body></html>"""
#cherrypy.expose
def exit(self):
raise SystemExit(0)
class MyBGThread(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
self.start()
def run(self):
cherrypy.tree.mount(MyApp())
cherrypy.quickstart()
myThread = MyBGThread()
webbrowser.open("http://127.0.0.1:8080")
This code is based on the sample from the SingleClickAndRun on the cherrypy website:
http://tools.cherrypy.org/wiki/SingleClickAndRun
Note than in a normal WebApp you would probably use a templating engine and load templates from methods like main.
Something that would be nice would be to embbed a browser control in a gui window and close the server when the app exits.
For the security, you could possibly add an authentication scheme. There are a few that are supported by cherrypy, but you possibly could implement your own too, using tool modules.
I am looking to do the exact same thing (desktop app that uses an up to date HTML5 / CSS3 browser as the desktop app's GUI), only with Ruby (various reasons why I decided to work with Ruby). Its amazing the number of cross platform libraries people have come up with. But yet, few to no one, has done any work on trying to get a web browser to be a desktop app UI. Cross platform issue... well I won't say solved, but I will say several steps in the right direction taken.
To me this would be perfect with the new HTML5 / CSS3 standards coming out. I know it can be done with a web server running locally.
Another way might be like how the guys from “280 North” are doing what they do. They developed Objective-J (an extension of regular JavaScript that mimics how Objective-C extends regular C) and Cappuccino (the Objective-J equivalent of Objective-C’s Cocoa frame work on the MAC). They also developed “Atlas” which is 280 North’s version of Apple’s “Interface Builder” from Xcode, for their Objective-J and Cappuccino frameworks to build Internet Applications. Atlas is actually a Cappuccino web app running on your desktop as a desktop app. In this case they use the Narwhal… a cross platform, general purpose, JavaScript platform for developing JS apps outside of the browser (basically a specialized web server).
If any one can come up with an idea to make “Browser, direct connect to Desktop App” work without the need of a web server co-existing and still get to manipulate the local FS, I to would be very interested… Hmmm... Now that I think about it, I wonder if the new Google Chrome project “Native Client” can be used to do that. NaCL is much like Active X except you are not limited to a windows platform (but will be limited to the Google Chrome browser, at least for now). Only there is added security via Sandboxing, but you can manipulate the local FS… The more I think about it, the more I am beginning to suspect that it can be done.
Any thoughts?
In Windows, you could embed the IE ActiveX control, which uses the same rendering engine as IE. (That's a plus and a minus) You can set the ScriptObject property in your host code and access it in Javascript as window.external to do things that Javascript cannot do.
If you run a local webserver, you could have an exit link in the app that kills the websever.
You did not mention the OS you will need to target. But you might be able to create a program statared web server, then launced the default browser. Wait until the browser is terminated by the user and then shut down the web server.
So for example on windows you can use CreateProcess() to spawn the process
then MsgWaitForMultipleObjects() to wait until it is finished executing.
HTML Applications (HTA, for short) have been around for a while. You can read all about them here. They are basically HTML and Javascript with some extra options to create a window and with access to the local file system. They seem to be exactly what you want. It is Microsoft technology, so this will only work with IE on Windows systems. I've successfully used this as a front-end for a CD-ROM which was used to distribute software to first year students
Another option would be to use Adobe Air. I'm not all that familiar with the technology, but it seems to provide a framework to deploy web pages as desktop applications. I can't post a second link as a guest, but just google it and you'll find it soon enough.
Today, in 2023, you can simply use any installed web browser as GUI using the WebUI library.