Is there a generic DirectX 9 wrapper that can force widescreen resolution on old games? (I know that for most games the ui will break in horrible ways ^^, but maybe i get lucky on some)
Additional it would be nice if it can also force a specific screen in a multi monitor setup for exclusive fullscreen. (But I'm not sure if this is something DirectX manages?)
You can use dgVoodoo:
http://dege.freeweb.hu/dgVoodoo2/dgVoodoo2.html
However some browser declare it as imho false positive see e.g. the post of a malwarebytes reasearch engineer https://forums.malwarebytes.com/topic/183073-dgvoodoo-2-false-positive/?tab=comments#comment-1039768
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.
I have a desktop app based on HTML/JS that needs WebKit to function at a reasonable speed. Normally, I would live with IE behaving badly, but its JS engine is just too slow.
I would normally go to Appcelerator for this, but it seems they have discontinued their desktop SDK and left it for the "community"...
This needs to function on Windows PCs, or I would just use Fluid (http://fluidapp.com)...
Is there a simple Webkit wrapper that I can use, or should I build one really quick in something like Qt. I haven't used Qt in a while, so I'd have to look at it again and make sure WebKit is implemented in it...
While it is somewhat node.js-oriented, AppJS may offer what you're looking for. If it doesn't already support other scripting languages, it might at least provide a good example to start from.
Update: in the time that's passed since my original answer, it seems node-webkit fills a similar role but has gathered and maintained more momentum than AppJS. It's a little more focused, in that it doesn't attempt to provide much additional "framework" on top of simply exposing the node.js API to the window's JS context.
There's also https://github.com/atom/atom-shell, which I just learned of and may be similar.
One other thing to note is that (presumably with either, but at least with node-webkit), you MUST be cautious of any XSS-like vulnerability in your app that an attacker could exploit to gain complete access to the user's native machine. So if you are simply needing to package an offline web app in a downloadable desktop distribution, you may wish to research more PhoneGap-like solutions (e.g. Mac OS X as PhoneGap platform) or a plain web view wrapper (like mentioned in the OP) that do not expose an entire OS-level native API — as node.js does — into the JavaScript environment.
We're in process of developing a desktop application which needs to record user's screen once he clicks a button. I read a tutorial about Adobe AIR, which says it is easy to do with AIR: http://www.adobe.com/devnet/air/flex/articles/air_screenrecording.html
But our preference is Titanium as we've explored it a little bit. So I want to know is that even possible? If yes, how can we get started with?
There's also an interesting solution which uses Java applet for recording, as demonstrated here: http://www.screencast-o-matic.com/create?step=info&sid=default&itype=choose
But again, we're not sure about JAVA and would like to know how can it be done? or if its even possible to run a JAVA applet in Titanium?
When you say "record screen", I'm assuming you mean video. Correct?
The only way to do this in Titanium Desktop right now is to take a bunch of screenshots and string them together (encoding would probably need to be done server-side).
Depending on how long your videos need to be, this probably won't work for you. I'm also not confident in how quickly you could capture screenshots, and if it would have a high enough frame rate to be usable.
Past that, a module could be developed for Desktop to support some native APIs to record video. That's not something I see on the horizon, though.
I hope this helps, albiet a rather dismal answer. -Dawson
I wish to write a utility to auto-hide the menu bar, much like the dock. This would
replicate the a OS X 10.4-only application "Menufela", but for Snow Leopard.
[[NSApplication sharedApplication]
setPresentationOptions: NSApplicationPresentationAutoHideMenuBar
| NSApplicationPresentationAutoHideDock];
This code auto-hides the menu bar (and dock), but only in when the application is the frontmost window. How would I go about applying this behaviour system wide, regardless of what application is open?
The only thing I can think of is an InputManager, but I haven't written one before, thus I'm unsure if this is the correct way to go about it..
Also it seems InputManagers are limited as of Leopard/Snow Leopard - from this SO question:
it won't run them in a process owned by root or whell, nor in a process which has modified its uid. Most significantly, 10.5 won't load an Input Manager into a 64 bit process and has indicated that even 32 bit use is unsupported and will be removed in a future release.
I'm not concerned about the "will be removed in a future release" (it just has to work on Snow Leopard), and I don't think root-owned processes are an issue (all GUI applications should be running as the current), but presumably the code would have to be injected into many 64-bit applications (Finder/Safari/etc)
(I originally asked this on SuperUser, here, but as there was seemingly no existing utility to achieve this, it's more relevant to StackOverflow)
The kiosk API is probably your best bet for this, though I haven't used it in years and don't know if it's even supported anymore.
http://developer.apple.com/mac/library/technotes/tn2002/tn2062.html
I hacked together a small SIMBL plugin to hide the Menu Bar: http://github.com/Crazor/MenuBarHider
It uses the SetSystemUIMode() Carbon call, which is not limited to 32bit apps.
I haven't used it on Snow Leopard myself, but the only way of injecting systemwide that even has a chance as far as I know is mach_star, and even that will be a bit tricky. Apple isn't making this easy these days, which is why a lot of the old hacks are failing to be updated either in a timely manner or at all.
This recent Cocoa With Love article has information on how to hide the menubar:
http://cocoawithlove.com/2009/08/animating-window-to-fullscreen-on-mac.html
However, using the CarbonAPI (SetSystemUIMode()) requires the app to be 32-bit and does not work outside the scope of the application.
Edit: and reading a bit further, it seems that this API doesn't do anything that -[NSApplication setPresentationOptions] can't do.