-
Notifications
You must be signed in to change notification settings - Fork 51
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
8d455ea
commit 8825fbe
Showing
6 changed files
with
104 additions
and
85 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8825fbe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@schriftgestalt This is the start of the refactoring that you mention in #278, right?
I'm not sure that this is going in a more maintainable direction that what is currently going on in "WIP UFO roundtrip" #244, so I'm starting a discussion about both approaches:
In WIP UFO roundtrip, my intent is to have:
UFOBuilder
andGlyphsBuilder
, one for each direction in which we want to translate objectsto_ufo_something
andto_glyphs_something
, for eachsomething
being an object or a concept to translate: style names, anchors, guidelines, layers...to_ufo_*
methods are indeed methods of the classUFOBuilder
, that's why they haveself
as first argument, and are attached to theUFOBuilder
class with imports inside the class body. Same forGlyphsBuilder
to_ufo_something
andto_glyphs_something
have been split into one file persomething
. Since they usually use the same data, they usually have the same arguments in the same order (I say that because I see that your are reordering arguments) and their implementation are symmetrical, which should be easy to check because they are next to each other.The good points are that
UFOBuilder
should be usable inside Glyphs.app, if given a native GSFont as argument. (and symmetrically can use any defcon-like class hierarchy).The bad points are that
UFOBuilder
andGlyphsBuilder
classes are big (even though they are split into small files). All the methods were grouped into those two classes so that they can always access some common data and configuration through their "self" argument. But there may be a better way?On the other hand, I see in what you've started that you want to move the "to_ufo" methods into the GS* classes. I foresee two main problems:
GSFontMaster::parent
although it is not documented in https://docu.glyphsapp.com/#gsfontmasterAlso the classes.py is already very long, it could also use a split into smaller files (but that's not a fundamental issue).
What is your take on this refactoring?
8825fbe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cast my vote for Jany's solution. Not 🍝 at all.
8825fbe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This branch is just me playing around with the builder code. I’m not insisting on doing it like that.
My idea was to have the
to_ufo...
andfrom_ufo
in the classes themselves.So instead of
builder.to_ufo_master(ufo, master)
you domaster.to_ufo(ufo)
So each object knows how to get in and out of ufo. So the implementation details of the input and output to ufo is handled in the same place.Maybe we can use the same file structure, but instead of side loading the methods into the Builder object, we could stick them at the GS* classes? That would keep the classes.py file clean.
That is missing. But basically all GS* classes in Glyphs.app have a
.parent
property. For the same reason as needed in this commit.8825fbe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the separation of concerns between the builder classes, on the one hand, and the GS* classes and the (defcon) UFO classes, on the other. The former act as mediators between the latter two, and only use public API of each; while each of the latter does not need to know about the other.