Do we need pre-10.9 compatibility?

[jeff-h]

There's some really good stuff in 10.9 in relation to JavaScript and Webviews.

I'm interested to know just how big a deal pre-10.9 compatibility is to everyone, especially now that:

a) 10.9 is a free upgrade

b) it's been out for a year and OS X 10.10 is just around the corner

c) every Mac released in the past 5-7 years can run 10.9 (See here).

Make your case for keeping compatibility with earlier versions! :)

[rawcreative]

Probably should've posted my comment in: #116 to here, but like I mentioned there, we should keep it at least until 10.10

That said, if we want to introduce functionality using the JavascriptCore changes in 10.9, I think it would make sense to either do it on another branch, or branch off the current feature set into a 10.7+ compatible branch for the time being.

[jeff-h]

I hear you on your pre-10.9 argument.

I hesitate to branch because I think most MacGap users probably already find it hard to understand why we even need to have MacGap and MacGapNode. A MacGap for 10.9+ and one for older would have a range of API differences that would be somewhat painful to keep in sync and/or document properly, for a workable upgrade path.

If we decided to call it MacGap 2 and thus halt non-critical work on the current code I could go for that idea. Thoughts?

[rawcreative]

Yeah that's essentially what I was getting at..

Ultimately though after digging around through the codebase and adding some new features which I'll submit PR's for shortly (added a StatusBar/Item API, and Context Menus), the more I'm realizing that one of the reasons that things are harder to implement in MG is a result of how the API was originally written. Everything is talking directly back/forth via the WebScriptObject, which is really inflexible, and because of this the MG API is extremely verbose and not very malleable. For instance, for the Status Bar api, to allow adding menus to Status Items, I'm having to re-write/roll my own menu API specifically for that which isn't very productive since I'm basically rewriting existing functionality. The same goes for Context menus, unless I rewrite the entire menu api (which I might just do), I'll have to basically repeat the process over again.

I think if things were reworked to use a consolidated Obj-c command interface, and paired with a central Javascript handler, similar to how Node-Webkit, Atom shell and Phonegap do it, it would make it much easier to implement more complex features. As well as making the API more user friendly, and familiar to Front end devs. Realistically it shouldn't be too difficult to accomplish, and a lot of the heavy lifting could be done via JS.

On May 17, 2014, at 6:49 PM, jeff-h notifications@github.com wrote:

I hear you on your pre-10.9 argument.

I hesitate to branch because I think most MacGap users probably already find it hard to understand why we even need to have MacGap and MacGapNode. A MacGap for 10.9+ and one for older would have a range of API differences that would be somewhat painful to keep in sync and/or document properly, for a workable upgrade path.

If we decided to call it MacGap 2 and thus halt non-critical work on the current code I could go for that idea. Thoughts?

—
Reply to this email directly or view it on GitHub.

[jeff-h]

Sounds brilliant to me. I'm in for this for sure; I don't have the skills to create such a thing from scratch but am definitely willing to do some "grunt work" getting a bunch of the basic functionality re-implemented, especially if your structural stuff is better than what we have now.

If you're happy to, I'd suggest calling this MacGap 2 as discussed previously. It carries all the same ideals as MG1 (principally lightweight-ness) and would render what we have now obsolete. I'd have to check with the project owner to confirm he's happy for us to go in this direction under the same name.

Your status bar and context menu additions sound great — and I can see how they would be a bit frustrating to implement in light of our current menu API code.

I think this frustration could be a consistent theme — a lot of stuff is becoming verbose.

e.g. yesterday I worked on an NSTask implementation to run shell scripts and should be able to commit that soon, but the code became very verbose as soon as I wanted to send stdOut to a JS callback, and fire a completion callback (not really sure how to implement stdIn), and make sure it is all capable of firing off multiple scripts concurrently.

Another example of increasing verbosity is the way we are handling JSContextRef.

Would you be willing to create a new repo and put some first thoughts together?

[maccman]

Sounds good! +1

On Sat, May 17, 2014 at 7:18 PM, jeff-h notifications@github.com wrote:

Sounds brilliant to me. I'm in for this for sure; I don't have the skills
to create such a thing from scratch but am definitely willing to do some
"grunt work" getting a bunch of the basic functionality re-implemented,
especially if your structural stuff is better than what we have now.

If you're happy to, I'd suggest calling this MacGap 2 as discussed
previously. It carries all the same ideals as MG1 (principally
lightweight-ness) and would render what we have now obsolete. I'd have to
check with the project owner to confirm he's happy for us to go in this
direction under the same name.

Your status bar and context menu additions sound great — and I can see how
they would be a bit frustrating to implement in light of our current menu
API code.

I think this frustration could be a consistent theme — a lot of stuff is
becoming verbose.

e.g. yesterday I worked on an NSTask implementation to run shell scripts
and should be able to commit that soon, but the code became very verbose as
soon as I wanted to send stdOut to a JS callback, and fire a completion
callback (not really sure how to implement stdIn), and make sure it is all
capable of firing off multiple scripts concurrently.

Another example of increasing verbosity is the way we are handling
JSContextRef.

Would you be willing to create a new repo and put some first thoughts
together?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/117#issuecomment-43429545
.

Alex MacCaw

+1.415.624.7665
@maccaw

http://alexmaccaw.com

[jeff-h]

@maccman, thanks for your support!

@rawcreative, it would be awesome if a code restructuring enabled users to pick and choose from the list of commands, and only compile in those they need. This would have big positives for keeping apps tiny, but also for security. Why compile in full filesystem access or shell script task running if you don't need them?

@maccman I don't want to go back on my promises :) but how would you feel about us including nodelike (https://github.com/node-app/Nodelike) into this new hypothetical MacGap 2, especially if all commands are optional? It upholds our lightweight ideals since it is not a full node binary (it leverages the new OS X 10.9 JavaScriptCore features to provide a node-like API). It adds about 900KB to a compiled MacGap app from my recollection.

One big upside would be that we would no longer need to maintain two separate repositories (MacGap and MacGapNode) if we could merge nodelike in as standard.

[jeff-h]

I've consolidated notes (and added a couple of others) into https://github.com/maccman/macgap/wiki/MacGap-2-planning

[rawcreative]

@jeff-h Already ahead of you on that one.. I've already started to rework everything with a command registration methodology similar to PhoneGap's plugin system. I had initially debated on forking the cordova libs and reworking them for MacGap but after going through it, I think it'd end up being more work than just implementing various parts and pieces that would be appropriate for OSX.

[jeff-h]

@rawcreative Very awesome!

[rawcreative]

@jeff-h I have a (very) rough working version of the rewrite up if you want to check it out, the only part of the API that I've implemented so far is the Window commands (some of them) and events. When I get a chance I'll post a readme with the api differences. As is stands right now, any api getters use the webscriptobject directly and all setters use a bridge so that callbacks and arguments can easily be sent to Obj-c. I will most likely end up changing getters to use the bridge as well so the commands can be loaded on demand rather than right when the app loads.

[jeff-h]

Wow, this is huge — initial reaction is that I love your node.js-ification of things (stylistically). Reading through the code I have lots of questions relating to my understanding of the approaches you've taken e.g. using the iFrame in exec.js, and the whole command queuing concept. However it's probably best that I save them until I've had a crack at adding a couple of simple commands myself.

I've approached @maccman about a restructure of the project so we can more easily move forward on MG2.

[rawcreative]

The iframe is used primarily because web views won't allow custom schemes/protocols sent via XMLHttprequests without implementing them with a custom NSUrlProtocol, so while it can be done, I just didn't see the need. The commands are queued because they aren't talking directly between contexts, they are staged in the queue, and then a message is sent back/forth between contexts using the webview's stringByEvaluatingJavascriptFromString method. Using this method complex objects can be passed back and forth between contexts, even without the Javascript bridge in 10.9. Now whether this method would be needed in 10.9 I don't know. I honestly haven't even looked into it.

On May 21, 2014, at 7:55 PM, jeff-h notifications@github.com wrote:

Wow, this is huge — initial reaction is that I love your node.js-ification of things. Reading through the code I have lots of questions relating to my understanding of the approaches you've taken e.g. using the iFrame in exec.js, and the whole command queuing concept. However it's probably best that I save them until I've had a crack at adding a couple of simple commands myself.

I've approached @maccman about a restructure of the project so we can more easily move forward on MG2.

—
Reply to this email directly or view it on GitHub.

[gobijan]

Would it make sense to move the codebase to Swift?
If we plan to move to Swift the question is answered by Apple since it seems that Apps compiled with Swift are backwards compatible till 10.9 (see: http://stackoverflow.com/questions/24001778/do-swift-based-apps-work-on-os-x-10-9-ios-7-and-lower).

[rawcreative]

@tschundeee I'd say eventually it might be a good move but definitely not right away.

Swift as a language is great and easy to learn, but actually working with the Cocoa API's in Swift is a different story. I spent most of the day yesterday playing with it and while the language documentation itself is good, everything related to Cocoa is pretty vague and very high level. Many common cocoa patterns are only explained briefly (like delegation for instance), and concepts like KVC/KVO are completely undocumented as of yet. Since MG2 is written entirely using the new JavaScriptCore framework (which is still completely undocumented other than the header files) and makes heavy use of the JSExport protocol that requires explicit declaration of the commands to be exported to JS inside the header file; how this would even work in Swift is totally unclear at the moment.

I think things will become a little more clear later on in the week after some of the WWDC Swift sessions have gone into more detail (there's 4 scheduled), as well as Apple deepens the documentation on interacting with the Cocoa apis via Swift.