It embeds a node.js server in the background (soon it will embed a custom Node server were I forked libev to use libdispatch on the mac and run behind inside a secure XPC server that launchd will manage on the Mac). Then using a Unix socket, it serves up through a custom webkit protocol handler. Two way communication to the frontend from a custom webserver written in Cocoa.
Instead of going down the road of trying to write Cocoa code with Javascript, instead just surface what you need as you need to your own backend. It's abstract so that it can be reused in other applications on other platforms in the future. Node.js was a good solution because it offers sandboxing and eventbased IO which for my first use case (Campfire) made prefect sense.
Doing this kind of binding with a generated kind of interface is always going to keep fighting an abstraction. (Like fighting some C++ lib you wrapped and are trying access through SWIG). My approach you just use the tool best suited for the job and embrace both Cocoa and Javascript.
Sitting next to the developer of MacGap (we both work at Twitter), the first thing that I asked was "what about Fluid?" http://fluidapp.com/ -- and Alex's first retort was that this was open source, and free.
It's a good point, but I felt that it was enough of a code change to fork - and callback-mac wasn't getting that much love (or accepting pull requests). However, it may be that that project gets merged back in, as I might be made the official maintainer.
I'm curious why Mozilla's Prism (XUL Runner) wouldn't be a candidate for forking in a project like this since it would allow for cross-platform (Windows/ Linux support)?
Fluid is great, but can be verrrrrrry buggy. I know the developer that makes it, and he's a great guy. I've been waiting for someone to put out a more solid replacement and hopefully this is it.
I've tried a lot of WebKit wrappers and the #1 problem is WebKit alone doesn't have things like a hardware accelerated canvas, audio support, WebGL, etc. etc. - basically a whole lot of stuff on the browser layer rather than the layout layer. This makes them totally useless for HTML5 games!
It's a bit more complicated and requires you to get familiar with Qt's paradigms for things like resource management (I'm still struggling with how to access files outside a qrc), but it offers infinitely more flexibility by exposing the entirety of Qt (and C++) to you as needed.
For example, I wanted to write a frameless app with edge snapping. The two problems I ran across were:
- First, when expanding a window the mouse would leave the web widget and so Titanium would stop sending mouse events (as it should). To fix that I had to wrap my content and center it in a larger transparent <body> and then account for that in the movement code. Ugly, but do able.
- And then, edge snapping on the other hand is impossible. Titanium doesn't handle multiple monitors very well. In-order to get the dimensions of a desktop you've dragged into you have to drop it first and even then it's relative to the upper left corner of the primary display.
I realize these are very specific issues but they're trivial in Qt (I handle resizing and dragging in Qt so mouse position is no longer an issue, and QDesktop is extremely straightforward).
Furthermore, not every library is available in Javascript so it can be useful to fall back to C++. I'm still using mustache.js for templating but I won't be using Strophe.js for my jabber library, I can instead use quicker C++ power library (I'd like to use libpurple but that's a whole other mess itself).
You can easily embedd internet explorer frames in winforms and WPF. If you're using Visual studio its almost a drag and drop affair. To gain things like system wide notifications you will need to use interop to get to the win32 libs, but its fairly straight forward and well documented.
As far as I'm aware (and I'm speculating from articles I've read) is that full support for HTML apps is coming in Windows 8.
EDIT: or just use the other link provided in the other comment which has webkit support :)
I've looked at callback-mac in the past with the idea of making a web app seem native on OS X, however there was a few issues with the system level integration, namely the system menu bar and right click menus. Any thoughts on how to address these?
I started working on my own WebKit Mac app framework with a slightly different take (a Heroku-style procfile and a pubsub backbone), but never released it. I'm happy to see others getting traction with similar ideas.
IMHO shocking documentation, very poor developer support via their Q&A stackoverflow clone and a somewhat flaky / buggy implementation (which could be mitigated by better documentation + developer support) or (open sourcing the framework) or (hiring someone to foster a developer community - none exists right now).
Maybe their paid support is better, but based on what is publicly available, I doubt it.
Incidentally, Titanium Developer (The build tool that compliments the framework) has been deprecated in favour of Titanium Studio, which is based on Aptana.
Many Titanium devs don't like Studio, and so have forked (the recently open sourced) Titanium Developer to remove some annoying anti-features put there by Titanium.
It's a shame; the Titanium tools are fundamentally good and are nearly there, but IMHO are frustrating to work with due to inadequate testing and an ineffective user feedback loop.
It's still a work in progress but it's part of my tinderbox application.
https://github.com/zbowling/tinderbox
It embeds a node.js server in the background (soon it will embed a custom Node server were I forked libev to use libdispatch on the mac and run behind inside a secure XPC server that launchd will manage on the Mac). Then using a Unix socket, it serves up through a custom webkit protocol handler. Two way communication to the frontend from a custom webserver written in Cocoa.
Instead of going down the road of trying to write Cocoa code with Javascript, instead just surface what you need as you need to your own backend. It's abstract so that it can be reused in other applications on other platforms in the future. Node.js was a good solution because it offers sandboxing and eventbased IO which for my first use case (Campfire) made prefect sense.
Doing this kind of binding with a generated kind of interface is always going to keep fighting an abstraction. (Like fighting some C++ lib you wrapped and are trying access through SWIG). My approach you just use the tool best suited for the job and embrace both Cocoa and Javascript.