I am developing a Firefox add on, I pretend my add on to be able to run in both desktop and mobile devices. I think more or less everything is compatible with both environments, however there are pieces of code that I would like to run depending on whether the current device is mobile or desktop, so the question is if there is something like system.isMobile() that can be used in the following way:
var system = require("sdk/system");
if(system.isMobile())
console.log("firefox for android");
else
console.log("normal firefox");
As you can find at the system api documentation, there is a variable telling the operating system.
code:
var system = require("sdk/system");
console.log("system platform = " + system.platform);
output:
system platform = linux
disclaimer: I didn't tested on mobile environment.
You can use the System High-Level API. system.platform will contain the information on the type of OS the user is running.
You can use it like so:
var system = require("sdk/system");
var platform = system.platform // Will contain platform, i.e. Windows, Linux, etc.
// You can log this data to the console
console.log("System Platform = " + platform);
When you call system.platform, it will usually return one of the values listed on this page, converted to lowercase
Related
This is a portion of the code for the application below. Blitz3D is stating that the CreateWindow, CreatePanel, and SetPanelImage functions do not exist. Am I missing a library or something?
Global ResWidth% = 910
Global ResHeight% = 660
Global VersionNumber$ = "1.5"
Loadingwindow=CreateWindow("", GraphicsWidth()/2-160,GraphicsHeight()/2-120,320,260,winhandle,8)
panelloading = CreatePanel(0,0,320,260,Loadingwindow,0)
SetPanelImage(panelloading,"Assets\map_logo.png")
; create a window to put the toolbar in
WinHandle=CreateWindow("Map Creator SCPCBR v"+VersionNumber,GraphicsWidth()/2-ResWidth/2, GraphicsHeight()/2-ResHeight/2,ResWidth,ResHeight,0, 13)
Global MainHwnd = GetActiveWindow();User32.dll
HideGadget WinHandle
There are two different versions of BlitzBasic which you have to distinguish:
Blitz3D
BlitzPlus
Blitz3D supports many functions for 3D game development. BlitzPlus provides many functions for GUI design. However, there is no BlitzBasic version which supports both features at the same time.
In any case, you have three options:
"I don't need 3D features": use BlitzPlus instead of Blitz3D to compile your program
"I need 3D features, but my GUI does not have to look like Windows style": use a community plugin for Blitz3D to create GUI elements (e. g. Draw3D)
"I need 3D features and Windows like GUI elements": Implement your game menu(s) in BlitzPlus and the actual game in Blitz3D
I have something like this in a BUILD file. I am un/commenting lines based on the operating system. Is there a graceful way to do this?
# Ubuntu
#shared_libraries = [
# "libboost_atomic.so"
#],
# OSX
shared_libraries = [
"libboost_atomic.dylib"
],
I haven't tried this however the bazel-build/rules_nodejs uses this kind of approach by wrapping the native binary and querying its's Node JS OS API.
OS Name Function(uses context given from user running node.exe)
UPDATE
Check here
Setting up a C++ Toolchain
This seems to be what you need.
My motivation: I'm writing an app to help with some quantified self / time tracking type things. I'd like to use electron to record information about which app I am currently using.
Is there a way to get information about other apps in Electron? Can you at least pull information about another app that currently has focus? For instance, if the user is browsing a webpage in Chrome, it would be great to know that A) they're using chrome and B) the title of the webpage they're viewing.
During my research I found this question:
Which app has the focus when a global shortcut is triggered
It looks like the author there is using the nodObjc library to get this information on OSX. In addition to any approaches others are using to solve this problem, I'm particularly curious if electron itself has any way of exposing this information without resorting to outside libraries.
In a limited way, yes, you can get some of this information using the electron's desktopCapturer.getSources() method.
This will not get every program running on the machine. This will only get whatever chromium deems to be a video capturable source. This generally equates to anything that is an active program that has a GUI window (e.g., on the task bar on windows).
desktopCapturer.getSources({
types: ['window', 'screen']
}, (error, sources) => {
if (error) throw error
for (let i = 0; i < sources.length; ++i) {
log(sources[i]);
}
});
No, Electron doesn't provide an API to obtain information about other apps. You'll need to access the native platform APIs directly to obtain that information. For example Tockler seems to do so via shell scripts, though personally I prefer accessing native APIs directly via native Node addons/modules or node-ffi-napi.
2022 answer
Andy Baird's answer is definitely the better native Electron approach though that syntax is outdated or incomplete. Here's a complete working code snippet, assumes running from the renderer using the remote module in a recent Electron version (13+):
require('#electron/remote').desktopCapturer.getSources({
types: ['window', 'screen']
}).then(sources => {
for (const thisSource of sources) {
console.log(thisSource.name);
}
});
The other answers here are for the rendering side - it might be helpful to do this in the main process:
const { desktopCapturer } = require('electron')
desktopCapturer.getSources({ types: ['window', 'screen'] }).then(async sources => {
for (const source of sources) {
console.log("Window: ", source.id, source.name);
}
})
How can I start a process in mono using the Process.Start API? My best guess would be the following (in F#):
let start (path : string) =
System.Diagnostics.Process.Start("/usr/bin/env", sprintf "mono \"%s\"" path)
This seems to work in linux, but it is obviously not correct in Mono/Windows. Is there any way I could obtain the location of the mono executable programmatically?
It turns out that you can basically just Process.Start with just the target executable path, no need to specify the mono executable.
You can find the location of Mono on windows using the following registry keys
$version = HKLM_LOCAL_MACHINE\Software\Novell\Mono\DefaultCLR
$monoprefix = HKLM_LOCAL_MACHINE\Software\Novell\Mono\$version\SdkInstallRoot
where you use the version you found to find the mono prefix.
Taken from this page
Rather than starting a new instance of the CLR, you can start assemblies from within your existing instance. Microsoft documents the relevant functionality here: http://msdn.microsoft.com/en-us/library/yk22e11a%28v=vs.110%29.aspx. Mono implements this as well.
What you have to do is create a new AppDomain to provide you with an execution environment isolated from your current one, load an assembly in there, and execute it.
Example:
var domain = AppDomain.CreateDomain("Foo");
domain.ExecuteAssembly("Bar.exe");
I manually install my driver using an .inf file. Until now, I deleted the oem.inf and .pnf files from the inf folder to uninstall. Whenever I install a new driver I delete/uninstall the old inf and pnf files.
In my old uninstalls (by deleting .inf and .pnf files), I didn't modify or delete any registry settings.
In this case do I want to change or remove any settings from the registry (for example: devnode)?
You should use the SetupUninstallOEMInf function to uninstall the .INF (and subsequently .PNF) files. This will take care of the details. pnputil (on Vista and higher) should do the equivalent thing from the command line. However, this function will not delete drivers that are currently installed (e.g. associated with a devnode).
Why are you uninstalling the old driver first? The user might already installed your driver for at least one devnode. Why not use a Microsoft-sanctioned solution such as DpInst? It will do the work required to update the driver.
Passing SUOI_FORCEDELETE to SetupUninstallOEMInf wouldn't be a good idea, cause you'd end up with lingering .INF references in your devnodes (in the registry).
At work I wrote a utility I called DriverUninstaller that deletes the devnodes and then deleted the INFs. I only use this utility for uninstallations. Upgrades are handled by DpInst, as they should be. The flow is roughly:
Enumerate them with SetupAPI (e.g. by device class if your device class is unique)
For each devnode, call SetupDiCallClassInstaller(DIF_REMOVE, ...)
Call SetupDiBuildDriverInfoList to find all .INF files for my device
For each INF, call SetupUninstallOEMInf
If there'll be interest in this utility, I might be able to persuade my employer to open-source it :-)
As the other answer points out the API to remove drivers on Windows is the SetupUninstallOEMInf method but I figured I'd add a few important notes here:
the INF path parameter must be the file name only (must not include the full path!)
this API requires Administrator privileges (this is not much of a surprise)
on 64-bit systems, the method only works when executed in the context of a 64-bit process (ie. WOW64 doesn't work)
The SetupDiGetDriverInfoDetail API can be used to query information about the relevant INF file(s) to remove for a particular device. And the SetupDiEnumDriverInfo/SetupDiBuildDriverInfoList APIs can be used to enumerate all drivers for a particular device.
// given infFilePath - full path to inf as returned by a query using SetupDiGetDriverInfoDetail
TCHAR* infFileName = GetFileNamePart(infFilePath);
if(SetupUninstallOEMInf(pInf, SUOI_FORCEDELETE, NULL))
{
// success
}else
{
DWORD errCode = GetLastError();
if(errCode == 0x02)
{
// means that the driver INF file was not found
// most likely it was already uninstalled
}else if(errCode == 0x05)
{
// must run as administrator
}else
{
// some other error code.. handle appropriately
}
}
I've open-sourced the code for a tool I wrote to perform driver uninstalls for USB and Media/Image devices. Details here: http://mdinescu.com/software-development/30-driver-hunter-programatically-uninstall-drivers-in-windows