发表文章

[Objective-C] Mac 支持 Mac support[HLSpriteKit]

btraut 2017-10-9 29

有计划支持 Mac 上的 SpriteKit 吗?我开始尝试自己的港口, 但有一些决定, 需要在手势支持, 因为它是有点不同的 Mac。我喜欢使用一些实用的节点, 如 HLTileNode, 即使没有手势支持。

原文:

Any plans to support SpriteKit on Mac? I started trying to port myself, but there's some decisions that need to be made around gesture support given that it's somewhat different on the Mac. I'd love to use some of the utility nodes such as HLTileNode even without the gesture support.

相关推荐
最新评论 (17)
karlvoskuil 2017-10-9
1

如果你感兴趣, 我很感兴趣。我甚至没有为 OS X 做一个 Hello 世界, 但我会在明天或第二天试用它, 看看可以为第一次迭代做些什么。

原文:

If you're interested, I'm interested. I've not even done a Hello World for OS X, but I'll try it out tomorrow or the next day and see what can be done for a first iteration.

karlvoskuil 2017-10-9
2

更新: 我已经得到了一个剥离版本的 HLSpriteKit 编译下 OS X, 但需要经历和测试的一切彻底。 作为 Cocoapods 示例的一部分, 我将为 OS X 创建一个示例应用程序。 当一切都大致正常, 我会做一些基本的交互支持 OS X (以及 UIResponder 接口下 iOS, 我认为)。

原文:

Update: I've got a stripped down version of HLSpriteKit compiling under OS X, but need to go through and test everything thoroughly. I'm creating an example application for OS X as part of the Cocoapods example. When everything's roughly working, I'll do some basic interaction support for OS X (as well as UIResponder interface under iOS, I think).

karlvoskuil 2017-10-9
3

推动1.2.0 在 iOS 和 macOS 平台下的编译支持。
现在, 我将返回并为 macOS 添加一些交互功能。

原文:

Pushed 1.2.0 with support for compilation under iOS and macOS platforms.
Now I will go back and add some interaction features for macOS.

karlvoskuil 2017-10-9
4

已将e2f0b33推送到使用基本 NSResponder 交互支持的主机。
现在关闭;随时重新打开 (或打开单独的问题) 的反馈, bug 报告, 或功能的要求!

原文:

Pushed e2f0b33 to master with basic NSResponder interaction support.
Closed for now; feel free to reopen (or open separate issue) for feedback, bug reports, or feature requests!

btraut 2017-10-9
5

谢谢!

原文:

Thanks!

btraut 2017-10-9
6

@karlvoskuil: 终于有机会深入了解这一点。

您的更改看起来很棒, 并且一定会帮助我减少我的东西和 HLSpriteKit 之间的一些重复代码。

我仍然渴望的一件事是手势识别器路由系统。我敢肯定, 你会同意, 这是令人沮丧的, SpriteKit 希望您注册所有 GestureRecognizers 在 SKView 级别, 这个问题仍然存在于 Mac 上。我想我还要再跑一次, 把 HLGestureTarget 的东西移植到 Mac 上。如果我被卡住了, 我会在这里张贴。否则, 在接下来的几天内就会有一个拉请求。

再次感谢!

原文:

@karlvoskuil: Finally had a chance to dig a little deeper into this.

Your changes look great, and will definitely help me cut down on some duplicate code between my stuff and HLSpriteKit.

One thing that I'm still craving is the gesture recognizer routing system. I'm sure you'd agree that it's frustrating that SpriteKit expects you to register all GestureRecognizers at the SKView level, and that problem still exists on the Mac. I think I'm going to take another run at porting HLGestureTarget stuff to Mac as well. If I get stuck, I'll post here. Otherwise, expect a pull request in the next few days.

Thanks again!

btraut 2017-10-9
7

我取得了很大的进步, 但我遇到了第一个障碍。显然 NSGestureRecognizer 只支持一个目标/行动。我们需要多个。

将一组目标/动作对收集到一个数组中, 然后在每个触发器上调用它们都很容易, 但是我们在哪里设置该数组呢?我在这里的第一个尝试是添加一个 NSGestureRecognizer 的类别, 它添加了一个 addTarget:selector: 方法和一个实例变量来存储它们 (通过此方法), 但感觉相当恶心。我也 reeeeeally 生锈, 当谈到客观 C 和这种巫术可能是超越我。

思想?建议?

原文:

I'm making great progress but I hit my first snag. Apparently NSGestureRecognizer only supports one target/action. We need multiple.

It's pretty easy to collect a bunch of target/action pairs into an array and then call them all on each trigger, but where do we set up that array? My first attempt here is by adding a category for NSGestureRecognizer that adds a addTarget:selector: method and an instance variable for storing them (via this method), but it feels pretty gross. I'm also reeeeeally rusty when it comes to Objective-C and this sort of voodoo might be beyond me.

Thoughts? Suggestions?

btraut 2017-10-9
8

好的, 我已经完成了所有的工作,我有一个 reeeeeeally 粗略的草稿。在中, 它生成, 但我还没有运行它。我明天会继续做, 但现在你可以看看, 如果你喜欢。

原文:

Okay, I've worked through everything and I have a reeeeeeally rough draft. As in, it builds but I haven't run it yet. I'll continue to work on it tomorrow, but for now you can check it out if you like.

karlvoskuil 2017-10-9
9

哇, 太棒了! 我甚至不知道有一个 NSGestureRecognizer , 因为某种原因, 我认为这是所有 NSResponder 。 我们对使用手势识别器有着相同的偏见。

我今天已经没有时间了, 所以我可能要继续明天, 但我的想法到目前为止:

  1. 你的多目标/行动的计划是完全合理的。如果你的方式工作, 那么让我们这样做, 我们可以随时改变它, 如果我们认为它太丑陋。一个合理的选择是将目标/操作数组存储在 HLScene 中: 它拥有笔势识别器, 因此它可以拥有相关的目标/操作。
  2. 从快速看, 我看不到笔势目标有机会将自己添加到 UIGestureRecognizerNSGestureRecognizer 中。旧的方式: UIGestureRecognizer 开始识别一个手势, 并调用它的委托, HLScene , 看看是否可以。 然后, 该委托使用命中测试在场景中查找所有可用的笔势目标, 并询问他们是否对笔势感兴趣。 因此, 委托方法是 HLScene 中的方法, 您注释掉了: gestureRecognizer:shouldReceiveTouch: ; 我认为, NS 等效项是 gestureRecognizer:shouldAttemptToRecognizeWithEvent: 。特别是, 该方法调用每个笔势目标的 addToGesture:firstTouchSceneLocation:isInside:
  3. 当我添加 UIResponder 和 NSResponder 的东西, 我有一个命名问题的困难: 它是一个 "水龙头", 如果它是为 macOS? 在 HLGridNode 中, 例如, 有一个委托回调 gridNode:didTapSquare: 。 是否需要为 macOS 进行等效的 gridNode:didClickSquare: ? 我能否提出一个通用的以UX 为中心的名称, 并将其用于点击或点击: gridNode:didActivateSquare: (或选择或按)? 无论如何, 我决定, 我不允许使用 "点击", 当我的意思是 "单击", 因为 macOS 可能有一个触摸敏感的表面, 并能够响应两个点击单击, 在这种情况下, 这将是混淆, 如果我调用点击 "水龙头"。 我提到这一点的原因是因为 HLTapGestureTarget : 而不是将其更改为 iOS 和 macOS 的工作, 我想我们可能需要一个单独的 HLClickGestureTarget 或其他通用名称, 如 HLActivateGestureTarget
  4. 顺便讲一下, 我正在进行一个单独的比较, (理应) 澄清一些手势目标的东西。 (纯供参考, 你可能不需要知道这一点, 但以防万一它改变了你的任何东西: 打破的变化是, 我想停止调用 registerDescendent 为每个手势目标添加到场景。 我已经决定, 这是误导和不必要的。 在场景中调用方法的真正目的是将共享笔势识别器添加到 HLScene 中, 因此这就是应该调用的方法: needSharedGestureRecognizersForNode: 。 与已为同一目的存在的其他 needSharedGestureRecognizers: 方法匹配。
  5. 我想知道在哪里可以把 typedef 之类的东西放在你的 HLGestureRecognizer 。 我认为它属于 HLGestureTarget.h , 我想看看你是否同意。 我的理由: 1) 您需要的 typedef 为 HLGestureRecognizer 如果且仅当您包括 HLGestureTarget.h ; 2) HLTypeDef.h 与笔势目标无关; 3) 没有必要为所有的 HLSpriteKit 的通用 typedef 文件, 因为, 说如果有另一个类似的 typedef, 如一些东西, 使 SKLabelNode 和 HLMultilineLabelNode 可以相同地使用, 那么它可能属于 HLMultilineLabelNode, 和所有者不需要包括的手势目标的 typdef。

最后一个注意: 既然我已经抓住了你的远见, 我很乐意为这个改变做出贡献。 你用 NSGestureRecognizer 的东西做了沉重的举起。 我很乐意做一些整合工作, 如果这似乎乏味的你-例如, 我可以工作的变化, HLGestureTarget 和 HLScene。

原文:

Wow, that's fantastic! I didn't even know there was an NSGestureRecognizer; for some reason I thought it was all NSResponder. We share the same bias for using gesture recognizers.

I'm already running out of time today, so I might have to continue tomorrow, but here are my thoughts so far:

  1. Your plan for the multiple target/action stuff makes perfect sense. If your way works, then let's do it, and we can always change it later if we think it's too ugly. A reasonable alternative would be to store target/action arrays in the HLScene: it owns the gesture recognizers, and so it can own the associated targets/actions.
  2. From a quick look, I can't see where gesture targets get the chance to add themselves to a UIGestureRecognizer or NSGestureRecognizer. The old way: the UIGestureRecognizer begins recognizing a gesture and calls its delegate, HLScene, to see if that's okay. The delegate then finds all available gesture targets in the scene, using hit-testing, and asks them if they are interested in the gesture. So that delegate method is the method in HLScene.m that you commented out: gestureRecognizer:shouldReceiveTouch:; the NS equivalent, I think, would be gestureRecognizer:shouldAttemptToRecognizeWithEvent:. In particular, that method calls each gesture target's addToGesture:firstTouchSceneLocation:isInside:.
  3. When I was adding the UIResponder and NSResponder stuff, I had a hard time with a naming problem: Is it a "tap" if it's for macOS? In HLGridNode, for instance, there is a delegate callback gridNode:didTapSquare:. Do I need to make an equivalent gridNode:didClickSquare: for macOS? Could I come up with a generic UX-centric name and use it for either taps or clicks: gridNode:didActivateSquare: (or select or press)? Anyway, I decided that I wasn't allowed to use "tap" when I meant "click", because macOS might have a touch-sensitive surface and be able to respond to both taps and clicks, in which case it would be confusing if I were calling clicks "taps." The reason I'm mentioning this is because of HLTapGestureTarget: Rather than changing it to work for both iOS and macOS, I'm thinking we probably need a separate HLClickGestureTarget or else a generic name like HLActivateGestureTarget.
  4. By the way, I'm working on a separate diff to (supposedly) clarify some of the gesture target stuff. (Purely FYI, you probably don't need to know this, but just in case it changes anything for you: The breaking change is that I want to stop calling registerDescendent for each gesture target added to a scene. I've decided that it's both misleading and unnecessary. The real purpose of calling a method in the scene is to add shared gesture recognizers to the HLScene, and so that's what the method should be called: needSharedGestureRecognizersForNode:. That matches with the other needSharedGestureRecognizers: method that already exists for the same purpose.)
  5. I was trying to figure out where to put typedef stuff like your HLGestureRecognizer. I'm thinking it belongs in HLGestureTarget.h, and I want to see if you agree. My reasoning: 1) You need the typedef for HLGestureRecognizer if and only if you are including HLGestureTarget.h; 2) HLTypeDef.h doesn't sound related to gesture targets; 3) There isn't a need for a generic typedefs file for all of HLSpriteKit, because, say If there is another similar typedef, like something so that SKLabelNode and HLMultilineLabelNode can be used identically, then it probably belongs in HLMultilineLabelNode, and the owner doesn't need to include the typdef for gesture targets too.

One final note: Now that I've caught your vision, I'd be happy to contribute to this change. You've done the heavy lifting with the NSGestureRecognizer thing. I'd be happy to do some of the integration work if that seems tedious to you—for instance, I could work on the changes to HLGestureTarget and HLScene.

karlvoskuil 2017-10-9
10

注意: 我已经推了我的 HLGestureTarget 更改, 但恐怕会导致与您的提交发生各种冲突。 因此, 现在我已经推他们到分支no-more-注册-手势-目标。 如果你把 HLGestureTarget 和 HLScene 的工作交给我, 我会把我的改变作为主人;否则我会等你, 基你的工作。

原文:

Side note: I've pushed my HLGestureTarget changes, but I'm afraid they'll cause all kinds of conflicts with your commits. So for now I've pushed them to branch no-more-register-gesture-targets. If you hand off the HLGestureTarget and HLScene work to me, then I'll base master on my changes; otherwise I'll wait for you, and rebase on your work.

btraut 2017-10-9
11

你的多目标/行动的计划是完全合理的。如果你的方式工作, 那么让我们这样做, 我们可以随时改变它, 如果我们认为它太丑陋。

我只是跳回到这个, 所以让我测试, 并提出一个更强烈的建议的方式或其他。我特别紧张的沙包方式, 我调用提供的选择器, 因为基本上没有类型安全, 它会如何反应, 如果用户给它一个坏选择。这件事我会给你回复的。

因此, 委托方法是 HLScene 中的方法. 你评论: gestureRecognizer: shouldReceiveTouch:;我认为, NS 等价 gestureRecognizer: shouldAttemptToRecognizeWithEvent:。特别是, 该方法调用每个笔势目标的 addToGesture:firstTouchSceneLocation:isInside:。

哦!我对此感到困惑, 也许是因为我在3am 遇到了它。我没有意识到这是一种 UIGestureRecognizerDelegate 的方法。是的, 它不应该被评论出来, 和 Mac 对等应添加。

我在想办法把你 HLGestureRecognizer 的东西放在哪里我认为它属于 HLGestureTarget, 我想看看你是否同意。

完全合理我在一开始就把它分成了自己的文件, 假设我最终会得到更多的共享 typedef, 但它最终变得更容易, 只是使用 #ifdefs 来拆分平台特定的代码, 而不是在同一个代码中使用 typedef。

最后一个注意: 既然我已经抓住了你的远见, 我很乐意为这个改变做出贡献。你用 NSGestureRecognizer 的东西做了沉重的举起。我很乐意做一些整合工作, 如果这似乎乏味的你-例如, 我可以工作的变化, HLGestureTarget 和 HLScene。

那太好了!就像我说的, 我觉得我在这里有点不舒服。我只是想做一个跨平台的游戏, 我从来没有期望修改框架。:)那么, 最简单的分享方式是什么呢?我是否应该添加一个请求, 将我的分支带到您的回购中, 然后从那里进行?

原文:

Your plan for the multiple target/action stuff makes perfect sense. If your way works, then let's do it, and we can always change it later if we think it's too ugly.

I just jumped back into this, so let me test and give a stronger recommendation one way or the other. I'm particularly nervous about the hacky way I'm calling the provided selectors because there's basically no type-safety and it's unclear how it will react if the user gives it a bad selector. I'll get back to you on this one.

So that delegate method is the method in HLScene.m that you commented out: gestureRecognizer:shouldReceiveTouch:; the NS equivalent, I think, would be gestureRecognizer:shouldAttemptToRecognizeWithEvent:. In particular, that method calls each gesture target's addToGesture:firstTouchSceneLocation:isInside:.

Ohhh! I was confused by this, perhaps because I encountered it at 3am. I hadn't realized that this was a UIGestureRecognizerDelegate method. Yeah, it shouldn't be commented out, and the Mac equivalent should be added.

I was trying to figure out where to put typedef stuff like your HLGestureRecognizer. I'm thinking it belongs in HLGestureTarget.h, and I want to see if you agree.

Totally reasonable. I separated it into its own file at the beginning under the assumption that I'd end up with a lot more shared typedefs, but it ended up being easier just using #ifdefs to split platform-specific code rather than using typedefs within the same code.

One final note: Now that I've caught your vision, I'd be happy to contribute to this change. You've done the heavy lifting with the NSGestureRecognizer thing. I'd be happy to do some of the integration work if that seems tedious to you—for instance, I could work on the changes to HLGestureTarget and HLScene.

That would be great! Like I said, I feel like I'm a bit out of my depth here. I just wanted to make a cross-platform game, and I never expected to be modifying a framework. :) So what's the easiest way to share? Should I just add a pull request to bring my branch over to your repo, and you take it from there?

btraut 2017-10-9
12

好吧, 把更多的时间放在我的 NSGestureRecognizer 类别, 我敢肯定, 我已经得到它的正常工作。请参阅最新提交:

btraut/HLSpriteKit@a8760c0

我会提出一个请求, 这样你就可以接手了。让我知道我还能帮上什么忙。

原文:

Alright, put some more time into my NSGestureRecognizer category and I'm pretty sure I've got it working properly. See latest commit:

btraut/HLSpriteKit@a8760c0

I'll set up a pull request so you can take over. Let me know how else I can help.

btraut 2017-10-9
13

哦, 嗯。看来我不能提交一个新的分支的拉请求。要么你可以做拉自己或我可以提交一个拉请求后, 你为我创建一个分支。我会自己做这项工作, 但如果您在合并中使用最新的 HLGestureTarget 更改, 我会感到舒服得多。

原文:

Oh, hmm. Looks like I can't submit a pull request against a new branch. Either you can do the pulling yourself or I can submit a pull request after you create a branch for me. I'd do the work myself, but I'd feel a lot more comfortable if you worked through the merge with your latest HLGestureTarget changes.

karlvoskuil 2017-10-9
14

好了! 我已经把它拉到我的本地存储库, 我会整合它, 并把它推回, 当我有东西要展示。 接下来的几天, 我想。

原文:

Okay, got it! I've pulled it into my local repository, and I'll integrate it and push it back out when I've got something to show. Next couple days, I think.

karlvoskuil 2017-10-9
15

已推送c31f6e4

看来工作了!

我想我要做两个提交: 一个压扁版的请求, 然后我的变化。 但我的改变最终只是调整, 没有真正的物质, 所以我只是压扁他们与你的承诺, 并推它在你的名下。 希望没事!

当前的想法:

  1. 我想我这个手势转发下 macOS。 重写 mac 的示例项目是一种乐趣。 非常感谢您介绍我到 NSGestureRecognizer !
  2. 我看到我在日志里放了个错字 固定.
  3. 我的一个调整是继续区分 "点击" 和 "点击"。 正如您可以看到在示例项目中那样, 这会导致对常见笔势进行大量看起来很琐碎的条件编译。 我绝对愿意重新考虑这个决定。 我认为, "点击" 和 "点击" 应该永远是不同的-但我愿意有 HLSpriteKit 节点, 默认情况下, 以处理 higher-level 的概念, 如 "选择" 或 "激活"。
  4. 我要添加一些触摸板支持 HLScrollNode 下的捏手势 macOS。 我希望它会顺利。
  5. 我检查编译下的 xcodeproj 在 top-level 目录, 但我仍然是迦太基菜鸟, 所以我不知道是否有更多的我应该做的测试。 如果你看到任何明显的东西, 请告诉我。
原文:

Pushed c31f6e4.

It . . . appears to work!

I thought I was going to do two commits: a squashed version of your pull request, and then my changes. But my changes ended up being just tweaks, no real substance, and so I just squashed them in with your commit and pushed it under your name. Hope that's okay!

Current thoughts:

  1. I think I love this gesture forwarding under macOS. Rewriting the example project for mac was a pleasure. Thank you so much for introducing me to NSGestureRecognizer!
  2. Aw nuts I see I put a typo in the CHANGELOG. Fixing...
  3. One of my tweaks was to continue distinguishing between "click" and "tap". As you can see in the example project, that leads to lots of trivial-looking conditional compilation for common gestures. I'd definitely be willing to revisit this decision. I think "click" and "tap" should always be distinct—but I'm open to having HLSpriteKit nodes, by default, to deal with higher-level concepts like "select" or "activate."
  4. I'm about to add some trackpad support for pinch gestures on HLScrollNode under macOS. I expect it will go well.
  5. I check compilation under the xcodeproj in the top-level directory, but I'm still a Carthage noob and so I don't know if there's more I should do to test it. Let me know if you see anything obvious.
btraut 2017-10-9
16

干得好卡尔!我要花几天的时间来尝试所有的新东西, 但从高水平来看, 这一切对我来说都很好。

原文:

Great job, Karl! It's going to take me a couple of days to try all the new stuff out but it all looks good to me from a high level.

karlvoskuil 2017-10-9
17

马上关门! 随时重新打开 (或打开一个新的问题) 与反馈。

原文:

Closing for now! Feel free to reopen (or open a new issue) with feedback.

返回
发表文章
btraut
文章数
1
评论数
8
注册排名
60670