I have a webapp with "print invoice" and "print receipt" functions.
How could I accomplish to print in the thermal printer for printing receipts but using the laser printer for invoices 100% silently?
I understand this isn't possible without any client side software previously loaded installed, this functionality is needed just for certain computers. It doesn't matter if the solution is browser specific or OS specific. Also I understand "kiosk mode" allows me to print silently to the default printer.
I have no idea what could be a good solution but was thinking about a Chrome extension or Firefox addon with a custom printing function where I could trigger from javascript like
my_custom_print('printer_b')
or
my_custom_print('printer_a')
Still I have no idea if that is even possible with extensions/addons or need something like NPAPI, PPAPI, java applets, etc...
Any ideas about this?
I'm about 90% sure that you can't silently print to a printer using any technology built into the browser; since NPAPI doesn't work in Chrome anymore (as of version 45) and PPAPI was never something you could use to call native APIs unless you want to pass in special command line flags to enable your plugin, Native Messaging is most likely what you'd need to use for this.
Related
It looks like Chrome uses xdg-open, so it's sufficient to create a .desktop file for you application and register it via mimeapps.list.
Firefox doesn't appear to honour this. I also tried registering via gconftool as suggested at http://kb.mozillazine.org/Register_protocol#All_Firefox_versions, but Firefox still doesn't seem to recognise the protocol, and entering "myprotocol://foo" just triggers a search rather than launching my application.
Is there a foolproof way to do this on all Linux versions which supports all browsers? Or at least a list of common bases to cover which will work for the majority of distro/browser combinations?
Note: this must be do-able programmatically - I want the application to register itself
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
Here's the deal. I've animated + coded a variety of 'screensavers' in Actionscript3/Flash. They make extensive use of the timeline, AS3 code, the TweenLite library, and embedded fonts. That's the limit of my programming knowledge. I've tried, to no avail, to convert my .SWFs into screensaver files using a variety of software, such as InstantStorm. Somehow it never works, the code never executes properly, it's a disaster.
So, I'm wondering if it's possible to make a screensaver that simply contains an embedded browser, and have it point to my .SWF file, hosted on my web-server. Basically, imagine a full-screen website acting as a screensaver.
If this is possible, what is the EASIEST and FASTEST way for me to whip up a solution for both PCs and Macs? Language, etc. I'm hoping something that has a library I can simply draw from to embed the browser view :)
My startup is developing a product to do exactly this, it's called Screensaver Ninja and you can find it at https://Screensaver.Ninja.
You can set many different web pages with different timers. The configuration tool allows you log in and navigate to the page you want to display:
It uses WebKit, on Mac OS X it uses Safari's and on Windows it uses Chrome's and in both cases it has a separate session from any other browser installed on the computer.
Here's a small Windows-only solution:
https://github.com/cwc/web-page-screensaver/releases
You could modify this open-source one for the Mac so that it's hard-coded to your URL:
http://www.liquidx.net/blog/2010/11/13/webviewscreensaver-for-mac/
Modify hasConfigureSheet() to return NO and change the URL in kScreenSaverDefaultURL. And change the name!
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.