Greeting! I have an application Written in VB.net that uses Flash Player 10r45. My customers keep automatically updating flash player to the latest version of flash which effectively breaks this legacy application. Is there a way to install two separate version of Flash? Reprogramming large amounts of the application is not an option because of the age of the software, nor would it be profitable do more than a few day fix.
I can provide more details and go deeper into the code if needed, but I'm betting a short answer will be my answer.
thanks,
Depends on how you use Flash. If it is a browser, I would have a different suggestion than if your app uses it to show instructions or so.
Edit: There is no "easy" way to have multiple Flash versions installed.
Related
I've got a big ask here, but I am hoping someone might be able to help me. If there's another site you think this should be posted on, please let me know.
I'm the developer of the free app Amphetamine for macOS and I'm hoping to add a new feature to the app - keeping a Mac awake while in closed-display (clamshell) mode while not having a keyboard/mouse/power adapter/display connected to the Mac. I get requests to add this feature on an almost daily basis.
I've been working on a solution (and it's mostly ready) which uses a non-App Store helper app that must be download and installed separately. I could still go with that solution, but I want to explore one more option before pushing the separate app solution out to the world.
An Amphetamine user tipped me off that another app, AntiSleep can keep a Mac awake while in closed-display mode, while not meeting Apple's requirements. I've tested this claim, and it's true. After doing a bit of digging into how AntiSleep might be accomplishing this, I've come up with 2 possible theories so far (though there may be more to it):
In addition to the standard power assertion types, it looks like AntiSleep is using (a) private framework(s) to apply non-standard power assertions. The following non-standard power assertion types are active when AntiSleep is keeping a Mac awake: DenySystemSleep, UserIsActive, RequiresDisplayAudio, & InternalPreventDisplaySleep. I haven't been able to find much information on these power assertion types beyond what appears in IOPMLibPrivate.h. I'm not familiar at all with using private frameworks, but I assume I could theoretically add the IOPMLibPrivate header file to a project and then create these power assertion types. I understand that would likely result in an App Store review rejection for Amphetamine, of course. What about non-App Store apps? Would Apple notarize an app using this? Beyond that, could someone help me confirm that the only way to apply these non-standard power assertions is to use a private framework?
I suspect that AntiSleep may also be creating a virtual keyboard and mouse. Certainly, the idea of creating a virtual keyboard and mouse to get around Apple's requirement of having a keyboard and mouse connected to the Mac when using closed-display mode is an intriguing idea. After doing some searching, I found foohid. However, I ran into all kinds of errors trying to add and use the foohid files in a test project. Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app? I'm not asking for code help with that (yet). I'd just like some help determining whether it might be possible to do.
Thank you in advance for taking a look.
Would Apple notarize an app using this?
I haven't seen any issues with notarising code that uses private APIs. Currently, Apple only seems to use notarisation for scanning for inclusion of known malware.
Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app?
Taking a quick glance at the code of that project, it's clear it implements a kernel extension (kext). Those are not allowed on the App Store.
However, since macOS 10.15 Catalina, there's a new way to write HID drivers, using DriverKit. The idea is that the APIs are very similar to the kernel APIs, although I suspect it'll be a rewrite of the kext as a DriverKit driver, rather than a simple port.
DriverKit drivers are permitted to be included in App Store apps.
I don't know if a DriverKit based HID driver will solve your specific power management issue.
If you go with a DriverKit solution, this will only work on 10.15+.
I suspect that AntiSleep may also be creating a virtual keyboard and mouse.
I haven't looked at AntiSleep, but I do know that in addition to writing an outright HID driver, it's possible to generate HID events using user space APIs such as IOHIDPostEvent(). I don't know if those are allowed on the App Store, but as far as I'm aware, IOKitLib is generally fine.
It's possible you might be able to implement your virtual input device using those.
I want to make a little painting program. So i am going over if it's even possible. As with all good painting programs it needs to have pressure sensitivity. And i don't think i have ever come across anyway to get pressure sensitivity of mouse/tablet. Is there a workaround.
The thing i have come closest to is touch event that is supposed to have pressure property.
This question has been asked before but that was like in 2009. I am hoping that there would be something available this time.
Chrome apps are also an option.
As far as I know only Firefox support this through a proprietary property on the event object:
var pressure = event.mozPressure;
which keeps a value between 0.0 and 1.0.
Wacom has a plugin that can be installed to give browsers an API to read these sort of values from but I guess it only works with their own tablets.
Hello from the future world of 2022!
There is a PointerEvent API that appears to be supported by major browsers, and pressure can be read out from the PointerEvent.pressure property.
tldraw is an example of a project using this API.
Notes on operating system support for this:
macOS
I can confirm pressure-sensitivity with tldraw's drawing tool works for me on macOS, with either Chrome or Firefox, and a cheap Wacom tablet. Safari did not.
Linux
Chrome on Linux works out of the box; I used the Flatpak version. Your mileage may vary with the .deb or Snap package.
For Firefox, you may need to do this or this to get pressure-sensitivity working. There seems to be a regression with Xinput 2 support being tracked by bug #1207700, so maybe this will be fixed some day.
Windows
I don't imagine you'll have any problems on Windows, but I'm unable to test.
If you were interested in creating a web-based paint program in 2022, you might have a look at Pressure.js, which claims to support both pressure input and "3D Touch" present on some Apple devices in a single library. I have no first-hand experience with this library, though, so I can't back up those claims.
It's true this comes 9 years too late for your project. Sorry about that. But this question ranks high in search results for "pressure sensitivity javascript api," so perhaps it can still be useful to someone.
How to create a WAP website?
What software do I use?
Do I just need to use HTML coding or other type of language?
And after I created it, Can I view it on my own phone?
Do I need a server to let it run or I can just view it on my phone?
Can someone help please, its for my project.
Thanks alot.
What phones are you targeting? Any phone released in the last 3-5 years is able to view standard (X)HTML without issue - except for the fact that they mostly have very small screens.
Some phones do not support Javascript very well (but that is mostly changing, too) and most phones do not support Flash (yet - most newish phones except iPhone will probably support flash "soon", if not already).
The only other main difference is that most phones these days use a touch interface, rather than a traditional keyboard/mouse. That means you can't really do things like hover effects and so on.
But other than the smaller size, everything else is pretty minor.
I agree with the post above that unless you are targeting very old phones, there is probably very little point to working with WAP today - AFAIK the last official version was WAP 2.0 which was circa 2002.
WAP 2.0 used a streamlined version of XHTML. The best way to develop is to either navigate your phone to a standard HTTP server hosting your files - or download and use a simulator. I found the best practice was to develop the app until it worked on the simulator (which could often be directed to load local files) and then do final testing and tweaking with actual devices.
I need to build a fairly simple app but it needs to work on both PC and Mac.
It also needs to be redistributable on a disc or usb drive as a standalone desktop app.
Initially I thought AIR would be perfect for this (it ticks all the API requirements), but the difficulty is making it distributable, as the app would require the AIR runtime to be installed to run.
I came across Shu Player as an option as it seems to be able to package the AIR runtime with the app and do a (silent?) install.
However this seems to break the T&C from Adobe (as outlined here) so I'm not sure about the legality.
Another option could be Zinc but I haven't tested it so I'm not sure how well it'll fit the bill.
What would you recommend or suggest I check out?
Any suggestion much appreciated
EDIT:
There's a few more discussions on mono usage (though no real conclusion):
Here and Here
EDIT2:
Titanium could also fit the bill maybe, will check it out.
Any more comments from anyone?
EDIT3 (one year on): It's actually been almost a year since I posted that question but it seems some people still come across it every now and then, and even contribute an answer, even a year later.
Thought I'd update the question a bit. I did not get around to try the tcl/tk option at the end, time constraint and the uncertainty of the compatibility to different os versions led me to discard that as an option.
I did try Titanium for a bit but though the first impressions were ok, they really are pushing the mobile platform more than anything, and imho, the desktop implementation suffers a bit from that lack of attention. There are also some report of problems with some visual studio runtime on some OSs (can't remember the details now though).. So discarded that too.
I ended up going with XULRunner. The two major appeals were:
Firefox seems to work out of the box on most OS version, so I took it as good faith that a XULRunner app would likely be compatible with most system. Saved me a lot of testing and it turned out that it did run really well on all platforms, there hasn't been a single report of not being able to start the app
It's Javascript baby! Language learning curve was minimal. The main thing to work out is what the additional xpcom interfaces are and how to query them.
On the down side:
I thought troubleshooting errors was a sometimes difficult task, the venkman debugger is kinda clunky, ended up using the console more than anything.
The sqlite interface is a great asset for a desktop app but I often struggled to find relevant error infos when something didn't work - maybe i was doing it wrong.
It took a little while to work out how to package the app as a standalone app for both PC and Mac. The final approach was to have a "shell" mac app and a shell pc app and a couple of "compile" script that would copy the shells and add the custom source code onto it in the correct location.
One last potential issue for some, due to the nature of xulrunner apps, your source code will be deployed with the app, you can use obfuscation if you want but that's something to keep in mind if you want to protect your intellectual property
All in all, great platform for a cross-platform app. I'd highly recommend it.
Tcl/Tk has one of the best packaging solutions out there. You can easily wrap a cross-platform application (implemented in a fully working virtual filesystem) with a platform-specific binary to get a single file executable for just about any modern desktop system. Search google for the terms starkit, starpack and tclkit. Such wrapped binaries are tiny in comparison to many executables these days.
Many deride Tk as being "old" or "immature" but it's one of the oldest, most stable toolkits out there. It uses native widgets when such widgets exist.
One significant drawback of Tcl/Tk, however, is that it lacks any sort of printing support. If your application needs to print you'll have to be a bit creative. There are platform-specific solutions, and the ability to generate postscript documents, and libraries to create pdfs, but it takes a little extra effort.
Java is probably your best bet, although not all Windows PCs will necessarily have Java (most should). JavaFX is new enough you can't count on it - you'll probably find a lot of machines running Java 1.5 or (shudder) 1.4. I believe recent Mac OS still ships with 1.5 (latest version may have changed to 1.6).
Consider JavaFX
It would run everywhere with a modern JRE ..!
AIR could be an option, but only if you don't mind distributing two different files (the offline runtime installer and your app), and expecting the user to run one and then the other. You do have to submit an online form at Adobe's site saying you agree to distribute the offline installer as-is, rather than digging out individual DLLs or whatever, before they give you the installer.
Unfortunately there's currently no way to get both an AIR app and the runtime to install from one file though. I'm not sure what the deal with Shu is, or whether it's doing anything that isn't kosher.
i would recommended zink. it has all the functionalities you require for desktop. however, the las time i used it it was a bit glitchy.
i was hung up by trying to write a 6M file to the disk. thought it trough and changed the code to write 512K chunks at a time (3min work, fast).
probably it still has some little annoying glitches like making you think on root lvl but the ease of use and the features are just way too sweet to ignore.
I may want to create a RIA but am wondering, whether Adobe AIR or Titanium is the way to go.
Do you think the open source version will last longer? Will it be better in anyway?
Just in case anyone comes back to this post, I'll add my 2 cents.
Titanium has come along way in the last few months. It now has support for Ruby and Python. You can code your own modules in C++ (eg, IRC) and compile Titanium to have support for that module (Or you can code modules in Py/Ru/JS).
You can use flex, flash and silverlight all within Titanium. All have been tested and work without a hitch :)
Although AIR isn't open source yet, the technology stack it's on (Flex, Webkit, etc) is open source. Titanium definitely looks promising but has no where near the momentum and support AIR has yet. Until it's been actually released and has several production apps running on it I wouldn't bet too much on it.If you're looking to get involved in an open source project and actually work and help develop it that's something else...
Just to clarify, AIR lets you use HTML/js to build your apps as well.
Neither, as both technologies are for creating desktop applications not RIAs.
Now if you were to ask how should you build your RIA... so that when, if, it comes to a point of you making a desktop version, which technology should you use, Flex or Javascript/HTML?
The answer becomes obvious once you decide between Flex or Javascript/HTML. If you do Flex then your desktop application will be in AIR; If you do Javascript/HTML your Descktop app will be in Titanium.
My suggestion, go with Flex - Air. Both are environments where State is made easy. Flex are written much like client (desktop) applications anyway as they have state.