- Screen dimensions - (screen.width, screen.height)
- Window dimensions - (window.innerWidth, window.innerHeight)
- Window X/Y position - (window.screenX, window.screenY)
...or whichever calculation works best for you.
The original work by Bjorn Staal https://twitter.com/_nonfigurativ_/status/172732259457002734 used localStorage, but I found sockets more fun, because if tweaked a bit, this can be shared with friends.
Here's a demo of how it works and the codebase: https://github.com/Momciloo/fun-with-sockets/
Also, thank you for voluntarily acknowledging that you were directly inspired by somebody else and giving them credit - the software industry could use more people like you.
Make your stuff from zero, like the rest of us!
Here the original creator is demoing the behavior on multiple monitors
IIRC you don't even need the sockets. One can simply use message channels between the windows. If a window opens child window, iirc it has special access over it (I say special, because usually different tabs/windows are isolated from one another) which might make a local-only version easy to implement too.
You need to shoot at the window boundaries, too, or the window shrinks. Additional windows appear later in the game with boss enemies.
Gameplay video: https://youtu.be/7iP68FZWVxM
Anyone have a link to what this was? The tweet is gone.
Even if we move to native world, making two different windows do the same instantly is not always trivial. For example, there have been articles about GUI toolkits making it impossible to have smooth window resizing. If we make everything ourselves (say, immediate drawing in response to WM_PAINT), we can only hope that the system notifies windows quickly, and that performance available is enough to pump bitmaps to screen. Or, better, we can try to use system-wide software or hardware compositor, add layers for individual objects, and only change their coordinates. Then we rely on compositor being good enough to handle 60/120/144/whatever updates per second when it's needed.
My personal theory about the lag is that positioning the window is not synchronized to the JS thread, so the window moves before the JS thread is aware, which means you see the square move after the window has already moved.
https://developer.mozilla.org/en-US/docs/Web/API/BroadcastCh...
I used the same LocalStorage sharing technique to update the target window when the setting had been changed on a separate browser window. Just listen for the storage.onChanged event for the update.
here's someone testing it out on Windows a few years ago, but I assure you even in the latest chrome on mac, it's at least as bad https://youtu.be/estvbRSj4LU?si=gq6-l4pWLC9yXqap&t=109
https://theannoyingsite.com/
||theannoyingsite.com^$document
uBlock filters – Badware risksSource code: https://github.com/feross/TheAnnoyingSite.
domain isn't mine anymore...
Here's to no one trying to patent it now!
Tcp and window.screenTop and screenLeft should get you there right? Hmm, yeah, 2008 is a long time ago though..
(Ludum Dare 35 Overall Winner) WindowFrame: https://youtu.be/CY7NUHn6GQg?t=273
Window Kill: https://youtu.be/7iP68FZWVxM?t=160
This maybe be something that can achieve that.
At first I thought this is an electron only thing. I get it that we gave up on fingerprinting resistance but this is like pissing on it's grave.
EDIT: privacy.resistFingerprinting set to true fixes the coords to 0
I'm trying to guess why, and can only imagine that at some point the idea was to support multi-window webapps, like maybe you'd have separate windows for documents and different tool palettes, and they'd want to know each other's locations to try to prevent overlaps? I mean, back in the day, framesets were another idea that experienced some popularity before being totally eclipsed by <iframes> -- all of this back in the era when everything was based on the multiple-windows paradigm rather than the multiple-tabs paradigm. Window.screenLeft apparently originated in IE [1].
Just a guess though. Very curious if there's any legitimate reason for it to continue to exist, or whether W3 ought to deprecate it.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/scre...
[1] https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...
It would be another matter if this was a very useful feature, but I don't think that it is.
Here's one use for it: Ads could sense that they are off-screen and withhold content until the ad is moved back in view. I could easily see screenX/Y being used for that. I mean, I hope not, but how am I going to stop it?
click jacking is always fun.
https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_C...
Sounds like OP wanted to use sockets for fun though.
>The original work by Bjorn Staal used localStorage, but I found sockets more fun, because if tweaked a bit, this can be shared with friends.
Who among us hasn't overcomplicated things for fun? :)
Anyway nice repo, thanks for sharing!
There are _a lot_ of posts that I have to scroll through of little to no value, but every so often I see a post by Yann LeCun or the lead developer advocate at TensorFlow or a paper someone has liked that catches my eye or a new model release.
"Machine learning LinkedIn", as it were, is a real thing; not sure whether this applies to other disciplines.