Closed brumm closed 4 years ago
@brumm Hi! What would the practical difference of this be? (This is not really in the context of this project.)
I can’t speak for @brumm but I’ve thought about this in the past as well. Technically speaking it would open a whole slew of scripting possibilities like networking and file i/o that are otherwise only available by wrapping inputs and outputs in tasks. Downside is that it requires a second process to be running, controlling Phoenix, or if Phoenix itsef can somehow be integrated into an “npm package” it could replace the Phoenix process entirely ¯\_(ツ)_/¯
.
Hey! The practical difference for me would be that I could package phoenix's functionality into a standalone application. I'd like to provide a graphical interface to window layouting, and would like to then apply those layouts to the actual windows themselves.
For this, I'd like to query screens, spaces and windows, then reposition and resize windows maybe and move them to specific spaces.
In the past I've attempted to write my own native module (via this) to do this stuff. I've managed to query windows, but got stuck on actually changing window positions because it involves dealing with that Accessibility API which was beyond my (really nonexistent) objc/c++ knowledge.
Regarding the second process, I'm not sure it would be necessary. I'd imagine it similar to this module (but with macOS support). A standalone version of phoenix as a library, which would open it up to interact with the entire npm ecosystem.
We talked about something that can achieve this functionality previously.
HTTP server that allows Phoenix to evaluate JS that's sent to it.
You could wrap up the transport into an npm module I guess.
Yeah, something like that would work. (At first I thought that the daemon mode was something I could use to achieve this, but it focuses on removing app ui, not having an interact-able process in the background).
I'd still advocate for a something like a 'phoenix-window' core library to exist. From what I've seen there's already people that ran into problems with the require function behaving in unexpected ways, which seems to be a side-effect of evaluating modern javascript code inside JavaScriptCore and falling short of current day expectations.
'Inverting' the control here and bringing phoenix functionality into standard node context would ensure that these expectations can be met, and alleviate the developer strain of attempting to be the host of a rapidly evolving JavaScript ecosystem.
Right now, there isn't a single npm package (as far as i know) that offers a way to interact with windows on macOS.
I do realize that my request is likely to be outside the scope of phoenix, which is more of a 'product' than a tooling component, but I figured I'd ask anyway :)
Extracting the core is likely not in scope, but it would anyway require a server to interact between the different contexts. That is something that is on the backlog.
Thats fair :) Thanks for your responses!
Hey, I just got some general questions:
I'm interested in writing my own window manager in JavaScript. I'd like to be able to use phoenix as a library from a nodejs/electron context, as opposed to my code being evaluated from within phoenix. Something like this:
Are there any plans to make phoenix available as an npm package like that?