Electron - simpler way of communicating between windows? - electron

I need to build a web based interface for a quick personal project and I'd like to use electron.
It's essentially a kind of gaming Zoom app with lots of bells and whistles.
The problem is, I need to have a main window that will run in fullscreen, which I capture with OBS and broadcast to a popular streaming service.
I also need another window, what I refer to as the Control Panel, to control elements in the main window that I work with behind-the-scenes, for showing graphics, playing sound effects, controlling video settings etc.
If I were to code this app for a web browser, I would have absolutely no problem, as I can create the secondary window from my main window (window.open) and the 2 windows can easily refer to one another and their documents.
In electron however, windows are essentially contained boxes. Communication between 2 windows has to be channelled via ipc essentially as encoded commands and interpreted by the main process...
So to control loads of elements and entities from my control panel, I'd either have to implement a complex messaging system, which frankly seems MASSIVELY unnecessary, or to be hacky I could simply issue javascript commands as strings to the other window with BrowserWindow.webContents.executeJavaScript()... but yuck.
I could also contain all the logic-y stuff in the main process, but again, this still requires a messaging system that I don't have the time to implement.
I guess I want to know if there's a better way.
I'm just imagining a scenario win which a developer has written a web-app that uses multiple windows and lots of direct window-to-window communication, and now they need to migrate it to electron... how would they best go about it without re-writing a ton of code?

Found my answer, 'nativeWindowOpen':
main_window = new electron.BrowserWindow({
webPreferences: {
nativeWindowOpen: true
}
});
I can now use window.open() from my main window and refer directly back and forth.
So now I can do this:
control_panel = window.open("./control_panel.html", "Control Panel", "width=720,height=480")
console.log(control_panel.document)
And from the opened window:
console.log(window.opener.document)
And I can refer to variables and document elements.
I couldn't find anyone mentioning this useful 'nativeWindowOpen' option when I was scouring stackoverflow et al earlier, only found it by reading documentation.

Related

Delphi Chromium Embedded (TChromium) - How to mute all sounds? [duplicate]

I have an application which has sound. I have a global property to mute the sound. The problem is, there's so many different things which can make sound, I would hate to iterate through different class types and mute/unmute their sound. Instead, I'm looking for a way to mute the sound on a global application level. I don't mean muting the entire system volume either.
One scenario: In Windows 7, you can open the Volume Mixer and adjust the volume of individual applications. While I don't intend to change this actual particular value (as I know it's Windows 7 specific), I would like to change the volume of everything in my application all at once. I would also need the ability to completely mute the sound of everything in my application. I need this ability to be compatible with Windows XP and above. I am assuming it will involve Windows API calls, but I have no idea what calls to make.
XP does not support per-application volume control. That capability was added in Vista. So what you are attempting to do cannot be done in XP by fair means.
There is software called IndieVolume that retro fits per-app volume control to XP. I can only imagine it does so by means of low-level hacking, DLL injection and so on. I doubt that's really an option for you.
What you're asking for isn't possible on XP; the OS simply does not support per-application volume levels.
You can accomplish what you want by creating a settings class that keeps things like SoundActive: Boolean or PlaySounds: Boolean or something similar. Place it in it's own unit, and have an initialization section that creates an instance of it and a finalization section that frees it (making it effectively a collection of global values).
Each unit that needs access to these settings simply uses the unit containing them, and adjusts behavior accordingly. So each of your child classes or forms or whatever would just need a check added:
if CurrentSettings.PlaySounds then
// Code that makes sounds, plays music, whatever.
The settings class can also contain methods that keep track of the current volume level (on XP, the system-wide level), and methods to increase or decrease volume using the MMSystem volume functions (there are tons of examples here and through Google of doing so). Your app can then use the OnActivate and OnDeactivate events to set the volume level when your app gains focus, and restore it to the proper volume when your app loses focus.
In Vista and higher, you can use the IAudioEndPointVolume interface I mentioned earlier and either the GetMasterVolumeLevel or SetMasterVolumeLevel methods to control system wide volume (I have an example of doing this, along with the appropriate MMDevAPI interface definitions) or device level volume (using IMMDevioce.Activate to select the proper device first and then the above IAudioEndPointVolume methods on the device interface received from IMMDevice.Activate in the ppInterface parameter).
For individual applications, you use the ISimpleAudioVolume interface, which has four methods: GetMasterVolume and SetMasterVolume, which control the volume level for your application's audio session, and GetMute and SetMute to allow you to retrieve the current mute flag value or set it respectively. (Larry Osterman of MS, who was one of the developers who worked on the new audio support in Vista and Win7, has a great starting point article on his blog about the types of audio in the new API and when to use each of them.)
It's conceptually possible to determine at runtime which operating system you're using, and to programmatically switch between using the MMSystem functionality on XP and earlier, and the MMDevAPI functionality on Vista and higher. Expecting someone here to provide the code for doing so is a little unreasonable, however. The links I've provided should get you started on the right track, and when you run into snags along the way specific help in working through those snags would be great questions.

Hidden window alternative

I use hidden window extensively but i read that might be problematic in the multi-process future. I use it mainly for canvas element so I can load png's onto it and then overlay other pngs on it and then save it as a png. I do scaling too. What would be the alternative, without hidden window assuming no windows available?
Thanks
For SDK Addons you could use the page-worker module, load a html page from a resource:// into it and interact with it through content scripts and the port api.
Sending images through the port api would be quite inefficient since it json-serializes right now, but hopefully they'll switch to structured clone in the future.
Of course right now the page worker API just uses the hidden window under the hood, but if the implementation were to change (e.g. being moved to the content process) the module the module API should stay the same.

How to put a specific monitor into standby mode? [duplicate]

I have 3 monitors, but I don't need them all turned on all the time. I can just shut them down with power button, but I want to use their standby mode, like Windows does when we let PC idle for a while - it shuts down monitors, HDD, etc.
But of course, I wanna keep using PC and let just that monitor on standby. Others must remain on and that one doesn't wake up even with me using PC.
Is it possible to do that? It would be great to have a shortcut like Winkey+1, 2, 3 etc to shut down and wake up each monitor.
An existing app with this feature is not likely to exist, but is there a Windows API function that can control monitor state, for each monitor in a MultiMonitor system?
The display control panel applet calls SetDisplayConfig to start or stop forced projection on a particular target
You can probably use MS Detours or some other API hooking tool to inspect the usage pattern of the API while using the applet to adjust display settings.
You'll want to try Display Fusion. You should be able to do what you're asking for using Monitor configurations.
I know I'm late on this but use DDC to control your display. You can easily create hotkeys that send a command via DDC to the display to turn-off. This would be equivalent to turning off the display using the button. Works like a charm for me. The only trick is that DDC command specs vary across monitor manufacturers but its not hard to find the right codes to send with the help of google.
Ready made tools also exist for this; search for anything that is related to DDC or EDID and you should find.
Be aware though that this does not remove the display from Windows which means that apps may find their way onto displays that are off and you will be looking for them.

Loading additional javascript code from firefox add-on content script

I'm writing something that I want to release as both a chrome extension and a firefox add-on.
The chrome extension is already available on github. I've factored my code into several modules using a module load format similar to what requirejs uses; I did this to separate the parts that were chrome-specific from the parts I hoped to re-use in the firefox add-on.
Specifically, I split up not only the backend work, but also the content scripts.
In chrome, when my content script needs to load another module, it sends a message to the background page saying "please load this module"; the script on the background page then does:
function onLoadLibrary(request, sender, sendResponse) {
var allFrames = request.allFrames || false;
chrome.tabs.executeScript(
sender.tab.id, {file: request.library.toLowerCase() + '.js',
allFrames: allFrames},
function () {
sendResponse({});
});
return true;
}
That is, I'm able to load additional javascript into the same sandbox as the content script that asked for that code. This is necessary to make module dependencies work.
In firefox, I can't figure out how to do this. I'll attach my initial content scripts through pageMods and by calling tab.attach from the "ready" event of tabs. That seems straightforward, but then if that content script needs to load more code I can't see how to do it.
There doesn't seem to be a way to access the sandbox my content script is running in from the main.js file so that I might inject more code into it. Even if I somehow kept a reference to the relevant tab instance (which only lets me inject into the top frame in any case), it appears that each new call to tab.attach puts injected code into a new sandbox. The object tab that's passed to my ready event handle isn't a real XUL tab that I could pass to require("tabs/util").getBrowserForTab; if it were, then I think I can follow through enough of the sdk code to create my own sandbox, though I'd worry about leaving accidental memory leaks behind.
I considered passing the code back to the content script through a "eval-this-code" message, but I really don't want to use eval in my extension because of security concerns; I also worry that using eval would make it difficult to impossible to get my firefox add-on approved for AMO. (Also, how would that interact when my add-on runs on sites with a Content Security Policy?)
The usage of traits to define the add-on API seems to close off access to objects such that I can't reach inside a Worker to get a reference to the sandbox my content script is executing in. At this point, it appears that I'd need to include nearly a full copy of the sdk in my add-on just to expose one method on WorkerSandbox.
Note: I'm using the Add-On sdk (the project formerly known as JetPack). I'm willing to use Components.utils.import if someone can tell me how to use that from inside an Add-On SDK-managed content script.
Content-scripts do not expose a public API to attach more scripts to a content-script sandbox after it was initialized. You should probably file an enhancement bug and state your use case, if there isn't one filed already (search first), and/or even come up with some patches yourself.
In cases where there is a DOM that your add-on own (widget), then it's just a matter of attaching another script tag.
For things like page-mods where there is no DOM you own, you're left with a couple of options, none of which is really satisfying. As you already found out yourself, the use of traits prohibits you from accessing "private" properties/methods.
Fork page-mod/tab/content-worker to provide the functionality you need. That would require creating your own copies of the modules and expose the necessary APIs to inject scripts into existing workers.
This is has a steep learning curve (but given that you already figured out details such as traits, should be doable for you), but more importantly hard to maintain as you need to make sure you keep up with the upstream. And AMO editors will not like you very much for it :p
On the plus side, you could try to get your stuff committed upstream, fixing this problem for everybody and become a hero to many authors using the Add-on SDK.
The eval method you propose. Not only is this eval a major source for security issues, but it also may be a performance killer, as right now IIRC evaled code will not use the JIT. And, of course, it will make us AMO editors cringe, even if used "correctly".
Do not use lazy loading at all, and specify all content scripts from the very beginning. This is what add-ons usually do (I'm almost inclined to say "always"). However, this conflicts with your current design, and depending on your add-on may pose a serious performance penalty for loading stuff you didn't really need in the end.
You could use the require mechanism to have most scripts as SDK module and not content-scripts. This is not always feasible, of course, e.g. when dealing with code that would normally modify the DOM in your content-script, but might work for some other stuff.
Replace page-mod, etc with your own Greasemonkey-like, enhanced API. This means lots of work, it is error-prone, security-sensitive and has to be maintained. So, it's not really a viable solution, IMO...
Components.utils.import does not help you. It isn't available to content-scripts anyway.

Background service that checkes change in a file

I haven't done any coding of this kind and would like some pointers how to start. The service will eventually do several things and perhaps someone has already thought of it made it happen.
The big picture is this: Detect if a PowerPoint presentation has been updated on the server. If it has extract the slides and save them as individual jpegs then upload them to a specific image list in SharePoint. All this has to happen without human intervention.
I assume this would be a window service project, right? Then a file stream property that with some property that deals with changes in the file?
As far as dissecting a .pptx/.ppsx files and get the slides converted, it there a "api" or some dll class?
What about uploading files to a library list on SharePoint automatically?
Thanks,
Risho
I've done this in Topshelf http://topshelf-project.com/, a windows service host for .NET.
https://github.com/Topshelf/Topshelf/blob/master/src/Topshelf/FileSystem/FileSystemEventProducer.cs
Since Windows has an event pump issue if events take too long, we also implemented polling on top of this since the FileSystemWatcher gets disconnected during those times.
https://github.com/Topshelf/Topshelf/blob/master/src/Topshelf/FileSystem/PollingFileSystemEventProducer.cs
Now, these producers are supposed to be tied to actors so they might seem a bit overly complicated for just checking on file system events. It's up to use if that model is useful or just the core part. Remember that you can often receive events even if the file is locked or not done yet, so handle those exceptions.
SharePoint has what is called a timer service for just these types of situations. Andrew Connell has an article regarding creating your own timer jobs.
http://www.andrewconnell.com/blog/archive/2007/01/10/5704.aspx

Resources