Description of the Problem
As NPAPI plugins will be deprecated in Chrome (maybe in Firefox too soon) and being part of a project (WebChimera) that is based on an NPAPI plugin. I've been thinking of different solutions to keep NPAPI support in browsers. (as porting this plugin to NaCL is currently impossible, but the plugin can be used in a frozen version of node-webkit that currently supports NPAPIs)
So I was wondering if it is possible for a browser page to open a node-webkit app on the user's PC, then using JS with/without jQuery to send data about the html element where the Node-Webkit window (with always on top set) should be to the app (maybe through a websocket) to always position it there.
I know I can get a html element's size, position in JavaScript, I also know I can track the scroll of the user and browser tab changes to do the necessary changes to the window size, position and visibility.
The Question
The thing that truly stops me from even attempting this is how would I know when a browser is not fullscreen, and how would I know the browser's position on the screen if it is not fullscreen either from the on page JS or from node-webkit directly. Another thing that should be a concern is what screen is the browser window on.
Am I the only one that has thought of such an endeavor with node-webkit, are there any open source projects attempting this?
Any thoughts or comments on this would be greatly appreciated as a solution to this would not only save NPAPI plugins in the near future but will also open a world where Node-Webkit can also be used as a viable solution to build browser plugins too. :)
This would involve a lot of painful hackery. You'd have to solve most of these issues on all platforms independently and rely on a lot of implementation details.
As a possible alternative, check out the plans for FireBreath 2.0 which will support plugins which can be loaded via NPAPI, ActiveX, and Native Messaging via a new protocol called FireWyrm. Currently there is no drawing support when using the FireWyrm interface and only Native Messaging is supported. Additionally it's not quite finished, though I'm getting close =]
Now it's possible to use libvlc to play video directly on NW.js/Electron page: https://www.npmjs.com/package/webchimera.js
What this project is: it's low level (written in C++) addon which use libvlc and allow decode video frames to JS ArrayBuffer object. In turn this ArrayBuffer object could be drawn on HTML5 canvas directly or with WebGL. This project use Node.js/V8 API directly and not use NPAPI at all, so will live even after NPAPI deprecation. Another good thing - perfomance of this (espesially if use WebGL) is comparable with original VLC player perfomance.
Simple usage example available at: https://github.com/jaruba/wcjs-player
Related
I'm diving into the world of Chrome Extension development, primarily because there is a very small feature that is missing in Chrome that I miss dearly. The context-menu option to "Set as background/wallpaper" like that found in Firefox. Sounds trivial, but it's convenient.
I have most of the "basic" stuff worked out with the manifest file, am able to install it, even managed to get it to show up as a context menu item.
The problem obviously is that I am wanting to mess with a user's OS-level settings which is extremely difficult because of security issues (fully understand this).
I found an extension that allowed this in older versions of Chrome, and it looked like the developer used some type of .dll and C++ to accomplish this.
I'm not really sure how to make this work.
Since that Chrome doesn't allow these kind of manipulations (such as your PC's settings), you will need to create a native application that will run beside your extension. When the user chooses the image from your extension and selects "use as wallpaper", you will use the native messaging API to send a message to your desktop application, that will set the wallpaper (and do whatever else you can't do within a chrome extension) for you.
You can use the chrome.wallpaper app api to set the wallpaper after using the messaging api to send the image from your extension.
Is it possible to create system hotkeys/shortcuts for Google Chrome Extension? I mean hotkeys that also works when Chrome doesn't have focus.
Yes, but it won't be trivial. To get truly global hotkeys you will have to use native messaging. You will need to create some application to run in the background and capture keypresses and then you can send those keypresses back to Chrome through stdout. This approach will require you to create an additional installer for your extension to install the native messaging app onto the user's system...before you could bundle your app along with the extension (using NPAPI) but that has recently been phased out. I have seen some discussion in the Chromium group about adding bundling support for native messaging apps, but nothing has been added (yet).
Another much easier option is to use the Chrome commands API which will enable you to use hotkeys across all Chrome windows (but not globally...). Just something to consider if "true" global hotkeys are not an absolute requirement since this approach is (much) less complex.
Global media keys will be added to Chrome soon, however. There is a good discussion about this feature to read here.
It's now part of Chrome: chrome://extensions/shortcuts
What technologies are used to power Quake Live?
Specifically, how do you create a web application that makes such extensive use of 3D in the browser? The service requires you to download and install a plug-in in order to play. How do you create such a plug-in, and how does it interact with the web site?
Browser programs are very simply, programs. They are given an interface to interact with the browser, but beyond that, they can do anything a normal native application can do, like use DirectX or OpenGL.
Internet Explorer registers plugins using ActiveX. Firefox, Chrome, Safari and most other browsers use Netscape's NSPlugin API.
The MDC has plenty of documentation on writing plugins for Firefox.
There is also a question on SO about writing plugins for IE.
I'm tyring to get phonegap up and running on blackberry storm (9530 simulator). I had been testing my webapp from withing BB's built in browser, and it was looking ok, but then it totally bit once I tried to look at the some code from within phonegap, even though I was pointing phonegap to the same url (I hadn't yet gotten to the point of running code locally on the device).
I tried a test case on google and got similiar results. see below. I suspect that I'm missing something basic here. I would have expect both images to be nearly identical.
Browser
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530WebGoogle.jpg
Phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530PgGoogle.jpg
[Update]
To shed some light on what is happening, I ran the browser and the embedded browser (phonegap) against the W3 mobile web acid test: http://www.w3.org/2008/06/mobile-test/
I definitely notice differences between the two, but I don't yet know the 'why' and the 'how-to-address'.
Acid via built-in browser
(source: eleganttechnologies.com)
BTW - I ran this earlier today and got a couple more green square than just now.
Acid via browser embedded into phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBb9530PgAcid.jpg
Disclaimer: I don't know anything about phonegap, but have a pretty good theory. By default the embedded browser control on BlackBerry uses an older version of the rendering engine than the BlackBerry browser itself does.
At the BlackBerry developer conference last year, a talk was given about this, and there's an undocumented option to use the newer rendering engine. \
The option ID is 17000 (yes, a magic number, which could change, use at your own risk etc), and should be set to true. Not sure how you'd pass this option through phonegap (I'm not familiar with the toolkit) but using the BlackBerry APIs it's something like:
BrowserContent content;
...
content.getRenderingOptions().setProperty(RenderingOptions.CORE_OPTIONS_GUID, 17000, true);
I don't know the specifics of the browsers you are using, but I do know that most of the big sites will detect your OS + browser combination to decide what HTML to show you.
If Google is seeing a different user agent, you might get a generic mobile version of the HTML instead os the Blackberry specific HTML you get for the built in browser.
If you have access to a web server, try hitting it with both browser setups and see if there is any difference in the log file. That might tell you something interesting.
As we can see in your Acid tests...
One browser (the built-in one) is reporting correctly as a BlackBerry9530, and the other (phonegap) is not presenting the user-agent ["Testing with ."].
In this case, Google is providing you with the default view of their homepage, whereas when you are reporting yourself as a BlackBerry device, you will get the BlackBerry specific rendering.
By the sounds of things, using phonegap is removing the default user-agent (most probably because it's not recognising your device). As phonegap is open-source, the best bet is to get in there, and debug it and find out what happens with the user-agent when the http requests leave the device and track it back from there.
Maybe one browser has capabilities that another one does not?
Hm. By looking at the screenshot I would say that the second page is probably missing some resources. It may be missing some images, scripts and the CSS files, which would explain different l&f. Knowing how Blackberry Browser Field API works, I would guess that the implementation that uses the BrowserField was not done correctly. Just my guess. In addition to that, when the browser field is initialized the caller needs to configure it properly by enabling the appropriate browser features - scripts, styles etc. Again, the API is done in a very weird way, I have gotten myself into this trap once. When setting the options, you cannot just create one mask (like CSS | WML | SCRIPT) and make one call. Options are numeric and, I believe, non-overlapping - but you still need to call the API for setting each option independently.
Also the way asynchronous loading of the resources for BrowserField takes time to understand.
Just my $0.02.
How can i create a browser component in J2ME which can display web pages inside an application? Is there any API available for this ? or is this really possible ?
My experiences:
J2MEPolish has HTML browser. It costs 990EUR per app and you need to use J2MEPolish to use it. But be warned: their HTML browser has many issues, it supports forms and other advanced elements, but if you try to get something you like then rendering quality is bad (e.g. no spacing, defaults to center view etc). Free evaluation/GPL is available.
PocketLearn J2ME HTML Component - http://www.j2mehtml.com/ seems to have less features but much better rendering quality. This is not free as well, and there they do not provide any useful evaluation download or public license fee info.
J2ME cHTML browser is free and open source, but no docs (and probably no quality too)
As far as I know, the only browser written in J2ME is Opera Mini (not to get confused with Opera Mobile, which is a different thing). It runs amazingly good even on very low end phones, but most of the HTML handling is done on a special server that Opera hosts, and the client gets optimizes, preformatted, binary data to display.
Doing everything on the phone using Java might be hard or even impossible. You'd be able to code up a browser that displays very basic HTML pages, but doing it right even for more complex pages seems to be impossible on J2ME because of the limited memory and CPU.
I could imagine that some high end phones come with a custom API to embed a native browser into you Midled, but the standart J2ME definitely does not have this.
The only portable way to display a web page in the browser is with:
MIDlet.platformRequest(String URL);
On some mobile, this will terminate the J2ME application though.
The Content handling API is what you're looking for.
That's JSR 211.
Unfortunately, to do what you want, you would need to find a handset that contains an implementation of JSR211 that is both complete and correct.
That doesn't exist yet as far as I know.
The only J2ME emulator that I know that may allow you to launch a web browser window (outside of a MIDlet) is the Nokia Series60 emulator. That doesn't have a complete implementation of JSR 211.
Try this
http://sourceforge.net/projects/fire-j2me/
Unfortunatley there are no built-in components in Java ME to render html.
You can try htmlBrowser component of the j2mePolish toolkit (www.j2mepolish.org)