Font.glyphs in Objective-C

Scripting
1

I am trying to make my first plugin completely in Objective-C. So far I got some things working that are all Apple Code related. Now I am trying to get the connection to Glyphs objects. How can I access the python equivalents to Glyphs.font aka Font, Font.glyphs and Font.selectedLayers? As soon as I can wrap my head around these, I might probably be able to puzzle other translations from the python documentation myself. Hopefully.

Edit:
I just found one way by climbing up the ladder via the parent attributes from the given Layer in the drawBackgroundForLayer: method. But I guess there is a more direct way?!

2

You can always check the python wrapper how those methods are implemented.

3

Okay, I could find my way by looking into the GlyphSILE.m by @SimonC – I also added what he called »// Horrible private things« :smiley: But I can make it work. Thanks so far.

1 Like
4

One more tiny tiny Objective-C API question:

I want to get the position of a layer’s anchor. According to the documentation and the object wrapper, the GSAnchor doesn’t have a position property, but it inherits from GSElement (NSObject) which has one. So Xcode eats my .position call, but still the console logs -[NSTaggedPointerString position]: unrecognized selector sent to instance

5

The .anchor property is a dictionary. When iterating it, you get the anchor names. Use [layer.anchors allValues].

1 Like
6

Ah, thank you sooo much!
Also: Happy new year :smiley:

7

But what when I use anchorsTraversingComponents ? It returns an array and I can NSLog the anchors in there like this GSAnchor <0x60000e283d40>: topright, {602, 740} but they still refuse to accept the position property.

8

Can you show the code?

9 
for (GSAnchor *thisAnchor in [thisLayer anchorsTraversingComponents] ) {
	NSLog(@"%@", thisAnchor);  // > GSAnchor <0x60000e283d40>: topright, {602, 740}
	thisAnchor.name // fails
	thisAnchor.position // fails

Same if I use GSElement instead. Obviously I don’t use allValues on the array.

10

You might try thisAnchor->name or similarly, thisAnchor->position. That is, I believe that you need to dereference the pointer.

Note that thisAnchor->name is semantically equivalent to (*thisAnchor).name, but the former is shorter and more idiomatic (at least in C).

11

That doesn’t work. But thanks anyway! I can access the anchor already as you see in my comment of the console log. It just refuses to return the name or position

12

Oh, well, sorry. I must admit that it has been a few years since I last wrote anything in Objective-C. Back then it all made perfect sense to me…

13

@ecuk .name and .position are ObjectiveC properties and not struct members. You still could do thisAnchor->_name the access the underlying member variable but that would mess things up quite easily and the compiler would not allow it.
(*thisAnchor).name doesn’t work as this only works for structs

@Mark how does it fail. On compilation or in runtime?

14

Thanks for the explanations :slight_smile:

@Georg: when I wanted to answer your question, I found that the error message in the compiler actually told me what my problem was. I forward declared GSAnchor, so stupid me forgot to import GSAnchor. Shame on me, so sorry! I thought I get used to objective-c quite a bit (there’s some progress, you’ll see soon). But those little things are not yet second nature :smiley:

btw: I’ll try to let my fingers off this funky arrow syntax with -> I had the impression you advised to try to avoid that.

15

The arrow syntax is greatly discouraged. Only for controlled internal use. The main difference is that you bypass the setter method.

1 Like
16

Very good to know, thank you

17

Yes, my bad. The arrow syntax is used often in C but much less often in Objective-C. Like I said, my Objective-C skills have clearly decreased in the last few years. (I wrote an audio voice synthesis app for the iPad in Objective-C a few years ago, but otherwise my primary language for decades (eek, plural) has been C.) It was only after I sent my original message—too late at night, I fear—that I remembered the semantics of Objective-C properties and their getters and setters. So thank you, @GeorgSeifert, for correcting me (and for refreshing my failing memory).

Anyway, @Mark I am glad you found the problem!

1 Like
18

It is always a good idea to read the error messages. Especially if it comms from clang. We are so used to the stupid error messages from makeOTF that one tends to ignore them.

1 Like