Font.glyphs in Objective-C


#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.


#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].


#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.


#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!


#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.