Is this project open-source, under some open-source license? Back when we saw it a few weeks ago, it looked like it was an open-source project, but now it looks like you're charging money for it... but the source is on GitHub?
Great work! Love the fast iteration; been using it since I found it on HN, and can't live without it.
Question: what does the license buy you? Are there limitations on usage or functionality without al license? Apologies if it's explained, but I couldn't find details on the site or github.
The thing I keep wondering about with this project is to what extent you can't already do this all with AppleScript, and to the extent you can't, why you wouldn't just add events/routines for AppleScript to get the same effect.
You might be able to do a lot of the same stuff in AppleScript, but that's AppleScript and this is Lua, which to me personally is a huge advantage.
And it's not quite a Lua "scripting bridge". That term usually implies automatic bridging between two programming languages, such as Lua and Objc, but all our bridging is manual.
The "Scripting Bridge" is a way to tie any language in to the Apple Event messaging architecture. I guess you can think of it as bridging Lua to Objc, but it is much more language agnostic than that. This is how you can have automation scripts on OS X writing in Ruby/Python/JavaScript/etc.
I get that your bridging is manual, but if you built on top of the scripting bridge you'd have something much more general, and your "manual" bridging could just be pure Lua code.
Having used "Scripting Bridge" for a few years now, I'm keenly aware of its very real and common caveats, and I'm not comfortable using it in any serious project. If users would like to write something like Hydra using only LuaObjC[1] or something similar, they're free to. But manually bridging function calls gives Hydra a robustness and stability that such an automatic bridge can never truly have.
I'm sure you wouldn't have bothered with the project if you didn't perceive it as being a better approach. I'm just ignorant to what the advantages are. Is the bridge really unstable? I hadn't noticed that with my admittedly limited exposure.
Comments
Author here. Happy to answer your questions in this thread.
Except for bug reports or feature requests, file those at https://github.com/sdegutis/hydra/issues instead.
Is this project open-source, under some open-source license? Back when we saw it a few weeks ago, it looked like it was an open-source project, but now it looks like you're charging money for it... but the source is on GitHub?
Could you clarify the license / money situation?
I'm writing a blog post to clarify this.
Great work! Love the fast iteration; been using it since I found it on HN, and can't live without it.
Question: what does the license buy you? Are there limitations on usage or functionality without al license? Apologies if it's explained, but I couldn't find details on the site or github.
It'll show a window periodically (without stealing key focus) to remind you to buy a license.
Makes perfect sense. Thanks for making it not too intrusive; not stealing key focus is a huge "nice guy" move.
License purchased.
The thing I keep wondering about with this project is to what extent you can't already do this all with AppleScript, and to the extent you can't, why you wouldn't just add events/routines for AppleScript to get the same effect.
Isn't this mostly just a Lua scripting bridge?
You might be able to do a lot of the same stuff in AppleScript, but that's AppleScript and this is Lua, which to me personally is a huge advantage.
And it's not quite a Lua "scripting bridge". That term usually implies automatic bridging between two programming languages, such as Lua and Objc, but all our bridging is manual.
The "Scripting Bridge" is a way to tie any language in to the Apple Event messaging architecture. I guess you can think of it as bridging Lua to Objc, but it is much more language agnostic than that. This is how you can have automation scripts on OS X writing in Ruby/Python/JavaScript/etc.
I get that your bridging is manual, but if you built on top of the scripting bridge you'd have something much more general, and your "manual" bridging could just be pure Lua code.
Having used "Scripting Bridge" for a few years now, I'm keenly aware of its very real and common caveats, and I'm not comfortable using it in any serious project. If users would like to write something like Hydra using only LuaObjC[1] or something similar, they're free to. But manually bridging function calls gives Hydra a robustness and stability that such an automatic bridge can never truly have.
[1] https://github.com/darrenclark/LuaObjC
I'm sure you wouldn't have bothered with the project if you didn't perceive it as being a better approach. I'm just ignorant to what the advantages are. Is the bridge really unstable? I hadn't noticed that with my admittedly limited exposure.
I'm just weary of any bridge to ObjC, having seen the caveats first-hand. But I suppose it's mostly just in principle.