sentialx / node-window-manager Goto Github PK
View Code? Open in Web Editor NEWManage windows in Windows, macOS and Linux using Node.js
License: MIT License
Manage windows in Windows, macOS and Linux using Node.js
License: MIT License
var windowInfo = []
var allWindows = windowManager.getWindows();
console.log(allWindowsD.length)
for(let i=0;i<allWindows.length;i++){
windowInfo.push(this.allWindowsD[i].getInfo())
}
App crashes if we try to get all windowInfo's at once
Is your feature request related to a problem? Please describe.
Currently installing node-window-manager
requires you to install Python and get node-gyp to work, which makes this rather hard to use.
Describe the solution you'd like
It'd be great if the node-window-manager
came with prebuilt binaries like robotjs. It looks like this wouldn't be too hard to achieve with https://github.com/prebuild/node-gyp-build and https://github.com/prebuild/prebuildify
Describe alternatives you've considered
Additional context
Bug description
I am trying to build our electron app with this package on a windows agent.
Unfortunately the installation fails with the following error.
8734 verbose lifecycle [email protected]~install: CWD: D:\a\1\buildsources\packages\launchpad-native\node_modules\extract-file-icon
8735 silly lifecycle [email protected]~install: Args: [ '/d /s /c', 'npm run rebuild' ]
8736 silly lifecycle [email protected]~install: Returned: code: 1 signal: null
8737 info lifecycle [email protected]~install: Failed to exec install script
8738 verbose teardown shutting down workers.
8739 info teardown Done in 0s
8740 verbose stack Error: [email protected] install: `npm run rebuild`
8740 verbose stack Exit status 1
8740 verbose stack at EventEmitter.<anonymous> (C:\hostedtoolcache\windows\node\14.19.0\x64\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
8740 verbose stack at EventEmitter.emit (events.js:400:28)
8740 verbose stack at ChildProcess.<anonymous> (C:\hostedtoolcache\windows\node\14.19.0\x64\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
8740 verbose stack at ChildProcess.emit (events.js:400:28)
8740 verbose stack at maybeClose (internal/child_process.js:1058:16)
8740 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:293:5)
8741 verbose pkgid [email protected]
8742 verbose cwd D:\a\1\buildsources\packages\launchpad-native
8743 verbose Windows_NT 10.0.20348
8744 verbose argv "C:\\hostedtoolcache\\windows\\node\\14.19.0\\x64\\node.exe" "C:\\hostedtoolcache\\windows\\node\\14.19.0\\x64\\node_modules\\npm\\bin\\npm-cli.js" "ci"
8745 verbose node v14.19.0
8746 verbose npm v6.14.16
8747 error code ELIFECYCLE
8748 error errno 1
8749 error [email protected] install: `npm run rebuild`
8749 error Exit status 1
8750 error Failed at the [email protected] install script.
8750 error This is probably not a problem with npm. There is likely additional logging output above.
8751 verbose exit [ 1, true ]
##[error]Error: Npm failed with return code: 1
Details:
node-window-manager
version: 2.2.4node-window-manager
version: -Additional context
The installation works on MacOS
Bug description
npm install node-window-manager
fails
To Reproduce
trying to install the "node-window-manager": "^2.2.4"
version to use it later in electron. If i understand correctly at the installation phase the electron version doesn't matter. It has to work first of all in node
Details:
node-window-manager
version: 2.2.4node-window-manager
version: 2.2.4Additional context
node -v 15.5.0 (not the electron node version)
npm -v 7.3.0
electron -v 16.0.7
Console output
npm ERR! path /Users/antonbrams/Desktop/Software/Studio 2/node_modules/node-window-manager
npm ERR! command failed
npm ERR! command sh -c npm run rebuild
npm ERR! > [email protected] rebuild
npm ERR! > node-gyp rebuild
npm ERR!
npm ERR! CXX(target) Release/obj.target/addon/lib/macos.o
npm ERR! gyp info it worked if it ends with ok
npm ERR! gyp info using [email protected]
npm ERR! gyp info using [email protected] | darwin | x64
npm ERR! gyp info find Python using Python version 3.7.3 found at "/Library/Developer/CommandLineTools/usr/bin/python3"
npm ERR! gyp info spawn /Library/Developer/CommandLineTools/usr/bin/python3
npm ERR! gyp info spawn args [
npm ERR! gyp info spawn args '/usr/local/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',
npm ERR! gyp info spawn args 'binding.gyp',
npm ERR! gyp info spawn args '-f',
npm ERR! gyp info spawn args 'make',
npm ERR! gyp info spawn args '-I',
npm ERR! gyp info spawn args '/Users/antonbrams/Desktop/Software/Studio 2/node_modules/node-window-manager/build/config.gypi',
npm ERR! gyp info spawn args '-I',
npm ERR! gyp info spawn args '/usr/local/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
npm ERR! gyp info spawn args '-I',
npm ERR! gyp info spawn args '/Users/antonbrams/Library/Caches/node-gyp/15.5.0/include/node/common.gypi',
npm ERR! gyp info spawn args '-Dlibrary=shared_library',
npm ERR! gyp info spawn args '-Dvisibility=default',
npm ERR! gyp info spawn args '-Dnode_root_dir=/Users/antonbrams/Library/Caches/node-gyp/15.5.0',
npm ERR! gyp info spawn args '-Dnode_gyp_dir=/usr/local/lib/node_modules/npm/node_modules/node-gyp',
npm ERR! gyp info spawn args '-Dnode_lib_file=/Users/antonbrams/Library/Caches/node-gyp/15.5.0/<(target_arch)/node.lib',
npm ERR! gyp info spawn args '-Dmodule_root_dir=/Users/antonbrams/Desktop/Software/Studio 2/node_modules/node-window-manager',
npm ERR! gyp info spawn args '-Dnode_engine=v8',
npm ERR! gyp info spawn args '--depth=.',
npm ERR! gyp info spawn args '--no-parallel',
npm ERR! gyp info spawn args '--generator-output',
npm ERR! gyp info spawn args 'build',
npm ERR! gyp info spawn args '-Goutput_dir=.'
npm ERR! gyp info spawn args ]
npm ERR! No receipt for 'com.apple.pkg.CLTools_Executables' found at '/'.
npm ERR! No receipt for 'com.apple.pkg.DeveloperToolsCLILeo' found at '/'.
npm ERR! No receipt for 'com.apple.pkg.DeveloperToolsCLI' found at '/'.
npm ERR!
npm ERR!
npm ERR!
npm ERR! gyp info spawn make
npm ERR! gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
npm ERR! clang: error: no such file or directory: '2/node_modules/node-window-manager/node_modules/node-addon-api'
npm ERR! make: *** [Release/obj.target/addon/lib/macos.o] Error 1
npm ERR! gyp ERR! build error
npm ERR! gyp ERR! stack Error: `make` failed with exit code: 2
npm ERR! gyp ERR! stack at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
npm ERR! gyp ERR! stack at ChildProcess.emit (node:events:376:20)
npm ERR! gyp ERR! stack at Process.ChildProcess._handle.onexit (node:internal/child_process:284:12)
npm ERR! gyp ERR! System Darwin 21.2.0
npm ERR! gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
npm ERR! gyp ERR! cwd /Users/antonbrams/Desktop/Software/Studio 2/node_modules/node-window-manager
npm ERR! gyp ERR! node -v v15.5.0
npm ERR! gyp ERR! node-gyp -v v7.1.2
npm ERR! gyp ERR! not ok
npm ERR! npm ERR! code 1
npm ERR! npm ERR! path /Users/antonbrams/Desktop/Software/Studio 2/node_modules/node-window-manager
npm ERR! npm ERR! command failed
npm ERR! npm ERR! command sh -c node-gyp rebuild
npm ERR!
npm ERR! npm ERR! A complete log of this run can be found in:
npm ERR! npm ERR! /Users/antonbrams/.npm/_logs/2022-01-18T15_08_32_271Z-debug.log
npm ERR! A complete log of this run can be found in:
npm ERR! /Users/antonbrams/.npm/_logs/2022-01-18T15_08_32_359Z-debug.log```
The bug happens when you try to setBounds of a MAXIMIZED Chrome window.
The setBounds operation does not work, meaning you cannot resize the window, position it where you want, etc.
If you try setBounds on another window (ex., Powerpoint window) it works even if the window's maximized.
The bug CANNOT be reproduced if the Chrome window is not maximized.
To Reproduce
chrome_win is a pointer to a MAXIMIZED Chrome window
chrome_win.setBounds({x: 365, y: 0, width: 600, height: 720})
Expected behavior
The windows should be resized accordingly to parameters.
Details:
node-window-manager
version: 2.2.4node-window-manager
version: N/AHello again ;)
I got an issue when using window.bringToTop
on a window that is opened multiple times from the same path.
exemple: i have two googleChrome opened and i try to bring to top one of them but the second one is bringing to top too. Resulting the one i wanted to focus and bring to top stay behind.
Cheer up your package is great and i look forward to help/fund you when the major issues will be fixed.
Best regards
There is a type in the quick start section of the documentation on npmjs.com/package/node-window-manager/
The first line of code is
const { windowManager } = require("window-manager");
when I believe it should be:
const { windowManager } = require("node-window-manager");
Bug description
windowmanager.getWindows() crashes electron process on macos Big Sur
Details:
node-window-manager
1.3.1:node-window-manager
1.3.1:After calling windowManager.getWindows()
repeatedly over a long period of time, RAM fills up very slowly and causes the application to crash when it reaches the limit.
The application consistently opens with an expected 5% of RAM being used, but then the percentage gradually increases until the application runs out of RAM and crashes. The entire process usually takes about an hour.
Considering the small number of packages that I am directly using, the stack trace I am getting leads me to believe that the problem is either with this package or with how I am using it.
Running with npm start --verbose
.
unsafe-perm in lifecycle true
CWD: C:\Users\NAME\Documents\GitHub\Webtop
Failed to exec start script
Exit status 3221225477
at EventEmitter.<anonymous> (C:\Users\NAME\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
at EventEmitter.emit (events.js:223:5)
at ChildProcess.<anonymous> (C:\Users\NAME\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
at ChildProcess.emit (events.js:223:5)
at maybeClose (internal/child_process.js:1021:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
npm verb pkgid Webtop@0.0.1
node v12.14.1
npm v6.13.7
npm timing npm Completed in 3163250ms
npm verb lifecycle Webtop@0.0.1~start: unsafe-perm in lifecycle true
npm verb lifecycle Webtop@0.0.1~start: PATH: C:\Users\NAME\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;C:\Users\NAME\Documents\GitHub\Webtop\node_modules\.bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\libnvvp;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\Razer Chroma SDK\bin;C:\Program Files\Razer Chroma SDK\bin;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Users\NAME\AppData\Local\Microsoft\WindowsApps;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Progr;C:\ProgramData\chocolatey\bin;C:\Program Files\Git\cmd;C:\ProgramData\chocolatey\lib\mpv.install\tools;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Program Files (x86)\Yarn\bin\;C:\Program Files\nodejs\;C:\Program Files\NVIDIA Corporation\Nsight Compute 2019.4.0\;C:\tools\cuda;C:\Users\NAME\AppData\Local\Programs\Python\Python37\Scripts\;C:\Users\NAME\AppData\Local\Programs\Python\Python37\;C:\Users\NAME\Anaconda3\pkgs\openssl-1.1.1d-he774522_2\Library\bin;C:\Users\NAME\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\NAME\AppData\Local\atom\bin;C:\Users\NAME\AppData\Local\Programs\Fiddler;C:\Users\NAME\AppData\Local\Yarn\bin;C:\Users\NAME\AppData\Roaming\npm;C:\Users\NAME\AppData\Local\GitHubDesktop\bin
npm verb lifecycle Webtop@0.0.1~start: CWD: C:\Users\NAME\Documents\GitHub\Webtop
npm info lifecycle Webtop@0.0.1~start: Failed to exec start script
npm verb stack Error: Webtop@0.0.1 start: `electron .`
npm verb stack Exit status 3221225477
npm verb stack at EventEmitter.<anonymous> (C:\Users\NAME\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
npm verb stack at EventEmitter.emit (events.js:223:5)
npm verb stack at ChildProcess.<anonymous> (C:\Users\NAME\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
npm verb stack at ChildProcess.emit (events.js:223:5)
npm verb stack at maybeClose (internal/child_process.js:1021:16)
npm verb stack at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
npm verb pkgid Webtop@0.0.1
npm verb cwd C:\Users\NAME\Documents\GitHub\Webtop
npm verb Windows_NT 10.0.18362
npm verb argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\NAME\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "start" "--verbose"
npm verb node v12.14.1
npm verb npm v6.13.7
npm ERR! code ELIFECYCLE
npm ERR! errno 3221225477
npm ERR! Webtop@0.0.1 start: `electron .`
npm ERR! Exit status 3221225477
npm ERR!
npm ERR! Failed at the Webtop@0.0.1 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm verb exit [ 3221225477, true ]
npm timing npm Completed in 3163250ms
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\NAME\AppData\Roaming\npm-cache\_logs\2020-03-06T21_24_24_445Z-debug.log
Follow the instructions here to install and run Webtop.
node-window-manager
version: 2.0.1node-window-manager
version: NoneI'm using a very slightly modified version of node-window-manager
located here in my repo that implements the fix for this issue. It is meant to be a temporary fix until the release is published to NPM.
The higher CPU usage is expected. However, I have 32GB of RAM. And only 25% RAM usage of 32GB is 8GB, which is 100% RAM usage on most standard systems. Yeah, very high.
code@kingdeMacBook-Air node-window-manager % npm run rebuild
[email protected] rebuild /Applications/code/github/node-window-manager
node-gyp rebuild
CXX(target) Release/obj.target/addon/lib/macos.o
In file included from ../lib/macos.mm:1:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12:
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:91:143: error: function does not return NSString
make
failed with exit code: 2node-gyp rebuild
npm ERR! A complete log of this run can be found in:
Platform: Windows
Currently, windowManager.getWindows()
method returns hundreds of application windows, including those are not actually visible (i.e. without having a window frame). I'm wondering if it's possible to filter out those windows and get a list of currently opened windows.
Bug description
The node-window-manager package does not work once packaged within an electron app using a version > 1.3.1
To Reproduce
Build an electron app with electron builder adding the build config:
"asar": {
"smartUnpack": true,
"externalAllowed": true
},
"asarUnpack": "./node_modules/node-window-manager/build",
Expected behavior
Once packaged the node-window-manager features like resizing, bring to top, ... should work with version 2.2.0 like it does with version 1.3.1
Details:
node-window-manager
version: 2.2.0node-window-manager
version: 1.3.1What does changed between v1.3.1 and v.2.x.x node-window-manager build that prevent the package from working once bundled with electron-builder ?
Note: always works fine in development mode
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | darwin | x64
gyp info find Python using Python version 3.8.2 found at "/Library/Developer/CommandLineTools/usr/bin/python3"
gyp http GET https://nodejs.org/download/release/v13.11.0/node-v13.11.0-headers.tar.gz
gyp http 500 https://nodejs.org/download/release/v13.11.0/node-v13.11.0-headers.tar.gz
gyp WARN install got an error, rolling back install
gyp ERR! configure error
gyp ERR! stack Error: 500 response downloading https://nodejs.org/download/release/v13.11.0/node-v13.11.0-headers.tar.gz
Bug description
When accessing windowmanager.getActiveWindow(), there is an uncaught exception :
Error: No native build was found for platform=win32 arch=x64 runtime=electron abi=80 uv=1 libc=glibc
at Function.load.path (webpack:///../node-window-manager/node_modules/node-gyp-build/index.js?:57:9)
at load (webpack:///../node-window-manager/node_modules/node-gyp-build/index.js?:22:30)
at eval (webpack:///../node-window-manager/dist/index.js?:23:133)
It has something to do with index.ts line 12. I pulled it locally and tried to change the require path, symlinked it to my electron project, and could not get anything to work. The same error always.
To Reproduce
Import the lib in an electron project running node 12 and the latest major electron version
IMPORTANT NOTE : to get the project to build, I had to change the prebuild command and add my node version :
"prebuild": "prebuildify --napi -t 12.18.0"
This may very well be related to the error, but without this change, the lib wont build.
MacOS 10.12.6, node 12.9.1, node-window-manager 1.1.0
windowManager.getActiveWindow()
always returns the same window as it is called first time, window-activated
event only fires once
The only way to update it is restarting the process or forking a new process
setInterval(()=>{
console.log(windowManager.getCurrentWindow().path)
}, 1000)
Hey,
I was wondering if there is any way to distinguish between a menu bar app and also the space? I am trying to capture and modify all of the open windows on a specific workspace/desktop. Right now when I call getWindows
, I get about 15 and they all return true for isWindow
, however only 1 window is actually open
I would like to use your library as a window manager for my electron app but i need to get the thumbnails and icons of every window, it's possible to accomplish that with your library like we could achieve with the desktopCapturer function of the electron lib ?
Best regards
Hey mate.
Found your module because looking for a decent NodeJS Window manager for Linux.
What is the state of this module? I see you've only pushed it recently.
NPM package does not exist, 404ing. Trying to node-gyp rebuild
but says windows.h is missing.
I would be happy to contribute to this as I need to grab the whole list of available windows.
If you could point me in the right direction, I would appreciate that :)
Is your feature request related to a problem? Please describe.
My primary use case for a library like node-window-manager is when I'm making a node app to manage the execution of other apps. When I use e.g. child_process.spawn() to launch an app, I get back a process handle with a process ID. Other libraries like npm node-process-windows have a pid scheme that matches the child_process pids, so I can usually find the window of the process I just launched and attempt to manipulate it (although node-process-windows appears unable to reliably e.g. bring a window to foreground). node-window-manager finds a lot of windows, but neither the window.id nor the window.processId match the child_process pids, so I can at best compare the window paths to whatever path I launched my subprocess at, but that gets sloppy and unreliable, especially when the target path had any degree of indirection (e.g. a relative path, .lnk shortcut, etc.).
Describe the solution you'd like
Ideally, window.processId is the actual process ID, consistent between all contexts that utilize processes and process IDs. Alternatively, if window.processId is already its own thing with its own expectations elsewhere, window should have some other property or getter returning a value consistent with subprocess.pid.
Describe alternatives you've considered
As mentioned, at least one competing library already does this- node-process-windows- it simply uses a helper tool that is not capable of certain manipulations on more current Windows builds. And while it's technically possible to compare process launch paths with window paths, discrepancies can arise which make path comparison only really useful for human-review sanity-checking or isolating which window ought-probably to have the pid I'm looking for.
Additional context
For managing windows with a multi-monitor workspace. It would be nice to provide functions for getting information about each monitor.
Maybe something from here:
https://docs.microsoft.com/en-us/windows/desktop/api/Winuser/nf-winuser-getmonitorinfoa
or
https://docs.microsoft.com/en-us/windows/desktop/gdi/multiple-monitor-system-metrics
Hello!
We are experiencing the issue with method from the npm package node-window-manager. Method getWindows() from dist/index.js does not return all windows but the first in the system. Our purpose is to find certain window via known process id.
As for now we fixed it directly in the package by adding return true
in the ffi.Callback like so
this.getWindows = () => {
const windows = [];
const callback = ffi.Callback("bool", ["int64", "int64"], (hwnd, lParam) => {
windows.push(new window_1.Window(hwnd));
return true // this line was modified
});
windows_1.user32.EnumWindows(callback, 0);
return windows;
};
Is it possible to update the npm package (include the method in newer versions)? I also saw getWindows is not supported in latest version
While I was testing stuff out on macOS X (Mojave), the window.minimize()
and window.restore()
failed and spilled out some errors.
const { windowManager } = require("node-window-manager");
const current = windowManager.getActiveWindow();
console.log(current);
current.minimize();
Error Thrown:
Error: A boolean was expected
at Window.minimize (/Users/victor/Documents/switch/switch/node_modules/node-window-manager/dist/classes/window.js:82:19)
at Object.<anonymous> (/Users/victor/Documents/switch/switch/build/test.js:4:9)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)
Am trying to investigate what happened. 😖
Bug description
After running the app for several hours and opening and closing various OS windows, I've notice that the memory use of the application consistently increases and decreases. After futher debugging, I found this addon to be the cause of most of the memory overhead.
To Reproduce
Expected behavior
** Actual Behavior **
CGWindowListCopyWindowInfo
and never releases returned data. Over 1.5gigs from the callDetails:
node-window-manager
version: 2.0.1Additional context
We need to call CFRelease
and [app release]
on pointer instances
windowManager.getWindows().forEach(window=>{
console.log(window);
console.log(window.getInfo())
})
[...]
Window { id: 3, processId: 148, path: '' } // WindowServer
Segmentaion fault: 11
It works if we filter it out
windowManager.getWindows().filter(window=>window.path).forEach
Bug description
In the new version (1.3.0), the method getWindows()
of class WindowManager throws an unexpected error.
Thrown:
Error: A number was expected
at Window.getInfo (C:\foo\node_modules\node-window-manager\dist\classes\window.js:164:28)
at new Window (C:\foo\node_modules\node-window-manager\dist\classes\window.js:15:42)
at addon.getWindows.map (C:\foo\node_modules\node-window-manager\dist\index.js:50:52)
at Array.map (<anonymous>)
at WindowManager.getWindows (C:\foo\node_modules\node-window-manager\dist\index.js:50:39)
To Reproduce
const { windowManager } = require('node-window-manager');
windowManager.getWindows();
Details:
node-window-manager
version: 1.3.0node-window-manager
version: 1.20Can i get all currently the window object to make traversal and get title of window
Bug description
Calling window.isVisible() returns true for every process that is running. Claims that every window is visible.
To Reproduce
windowManager.getWindows().forEach((window) => { if (window.isVisible()) { console.log(window.path); } });
Expected behavior
Should only return true if window is visible.
Screenshots
Details:
node-window-manager
version: 2.0.1node-window-manager
version:Additional context
Is your feature request related to a problem? Please describe.
Yes
Describe the solution you'd like
We need to support a higher npm version.
Describe alternatives you've considered
N/a
Additional context
My electron app uses npm version 9.
Hello, thanks for developing this package. Can you please tell me what's up with Linux? Do you need any help with developing this version of your package? I'd love to support you once Linux is added.
When attempting to use methods like getBounds
and setBounds
on window objects acquired with windowManager.getWindows
—or from new Window
—the application crashes. I've been able to use these methods in the past on the window object returned by windowManager.getActiveWindow()
. Is this some kind of permission or security issue?
I have an Electron Fiddle here: https://gist.github.com/Fauntleroy/84fde89e6ede40becffa1fe53132ab7b
Steps to reproduce:
Bug description
window.bringToTop flashes the window in the task bar as if it was focused, but doesn't bring it forward
Expected behavior
Bring to top should bring a window to top
Details:
node-window-manager
version: 2.0.1node-window-manager
version: Never used this before todayAdditional context
Working in electron, if that's relevant
Unfortunately using node-ffi won't work on Node.js 12 TooTallNate/ref#107
My use-case: i have an integer representing the id of the window i wanna share then i use directly new Window(id)
and getInfo give me exactly the right window but setBounds not working with this method.
My work around: loop over getWindows and use the window matching the id.
Expected behavior: first method should work directly.
Some code illustrating what i'm saying:
// first not working method
const selectedWin = new Window(parsedId);
// second working workaround
const selectedWin = windowManager.getWindows().find(window => {
return window.id === parsedId;
});
selectedWin.setBounds({
x: screenBounds.x + sideBarWidth + 15,
y: screenBounds.y,
width: screenBounds.width - sideBarWidth - 15,
height: screenBounds.height,
});
Best regards
Is MacOS support being actively worked on? One potential lead for how to do it is Phoenix:
Bug description
window.getTitle
method doesn't work on macOS Catalina, because now it requires some desktop capturer permissions.
Details:
node-window-manager
version: 2.0.0node-window-manager
version: noneA declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.