Closed rc1 closed 11 years ago
@rc1 No worries ^_^ (I'm thrilled that anyone even knows about this project!)
The web view binary, nib file and stuff are from Phonegap Mac, aka Apache Callback, aka Apache Cordova, etc…
See also: #1 & #8. I should really upgrade this to use https://github.com/maccman/macgap MacGap instead.
It's really easy to customize the webview and menu and stuff. You just have to put the binary file into the MacOS folder and the English.whatever folder into Resources and you're all set. Mac apps are way double hackable!
@subtleGradient Thanks for info! MacGap looks good. Key feature would be close the application when the window gets closed.
I wasn't able to find a matching nib for this to copy in. I tired using Cordova. Anyway I was able to edit the size of the window by running plutil -convert xml1 MainMenu.nib
which made the nib (hackably) editable...
This is an awesome project. Certainly hits a sweet spot.
@subtleGradient the quitting could be added... do you know the repo and commit reference from which you created the apache-callback-mac
binary?
I think I may have pushed my branch to my fork of callback. If not, it may be lost. I need to redo all that work using MacGap anyway though, so no huge loss.
@rc1 If you spawn the callback binary from within node you can close the application when the window gets closed by using
var chrome = spawn('./apache-callback-mac', ['-url', '"http://localhost:8004"']);
chrome.on('exit', function(){
process.exit();
});
@eerne that callback happens only when apache callback quits, not when its window closes. At least in the current binary. Thanks for the link, should be straight forward to add with this.
Oh, I tested with ⌘W that actually triggers the exit
event. The red button top/left does not trigger exit
. Would you try to add MacGap #8? =)
IIRC, All that's needed is https://github.com/maccman/macgap/issues/46
Cf. https://github.com/subtleGradient/callback-mac/commits/simplification Especially: https://github.com/subtleGradient/callback-mac/commit/b46c12b551a13311c05c36f5d45252a87eac0bde
I lost (or couldn't be bothered to find) the original code I used a while back, so a few months ago I was forced to redo the -url
patch. You should be able to get that same thing into MacGap.
If you beat me to it, please do let me know. I don't have any plans to work on this in the near future. Sorry
Also, you guys might be interested in this app I wrote using Appify-UI: https://github.com/subtleGradient/DeviceRemoteInspector.app
It has a bunch of tricks to keep log files, auto-update from git on quit, install missing dependencies, etc. Cf. https://github.com/subtleGradient/DeviceRemoteInspector.app/blob/master/Contents/MacOS/app.sh
One huge problem I solved was killing all the various subprocesses that I start whenever there's a crash or something. https://github.com/subtleGradient/DeviceRemoteInspector.app/blob/master/Contents/MacOS/app.sh#L141-149
@subtleGradient thanks for the link to the other app. If/hopefully I get a spare day I will have a go at adding MacGap.
I get the workflow of using arguments. Would be nice to use unix sockets or something for mac/node comms other than html. Did you ever have any thoughts about that? Also, I am guessing as is this wouldn't go through the app store? Sure a use full tool without anyway.
In Dri.app I'm using hook.io which uses socket.io for realtime communication between node.js and HTML. e.g. https://github.com/subtleGradient/DeviceRemoteInspector.app/blob/master/Contents/SharedSupport/Frontend/commands.html#L87-104
Socket.io is really simple to get started with.
Sorry, I didn't mean web sockets. At the moment the views are provided on localhost and a port. Meaning you can access / interact with it via a web browser. It arguably a bit messy. It could/would be good to have the Mac binary communicate with the node process over a UNIX socket connection.
For example, I made an App using Appify the which interacts with a node process which is handling may Open Sound Control layers. At moment, node.js servers the UI. But it wouldn't have to. But it still quicker than adding a V8 layer et all to a Cocoa App.
Stupid questions sorry.