Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Next Major Version Discussion #252

Open
MatrixSenpai opened this issue Apr 21, 2020 · 4 comments
Open

Next Major Version Discussion #252

MatrixSenpai opened this issue Apr 21, 2020 · 4 comments
Assignees

Comments

@MatrixSenpai
Copy link
Collaborator

I'm leaving this issue pinned as an open discussion for the community.

When it comes to Pro fonts (including Duotone), there's a few issues that we should consider.

  • Pro users have access to icons that do not exist in the Free font
  • SVG paths may be more beneficial for users with images and certain buttons (like bar/tab buttons)

With using SVGs comes the possibility that people may try to steal this font. And there's not really a way for us to verify with FortAwesome who is and isn't a Pro user.

So, we have two options as I see it. Either:

  1. Include some documentation on how to perform extra configuration to use Pro fonts, using some kind of automated script that re-generates the enum including the Pro icons and SVG paths for duotone.
  2. Continue on as-is, but provide some suggestions on how a user may configure Pro fonts for themselves.

If people have a preference, or have another idea, this is the place to discuss it

@MatrixSenpai MatrixSenpai self-assigned this Apr 21, 2020
@MatrixSenpai MatrixSenpai pinned this issue Apr 21, 2020
@MatrixSenpai MatrixSenpai changed the title Using Pro Fonts in this library Next Major Version Discussion Apr 28, 2020
@MatrixSenpai
Copy link
Collaborator Author

I've changed this issue to include discussion for the next major version. There's a few more points I'd like to consider.

  • Include an open protocol or class for FA-compatible elements, making them easily extendable, similar to how RxCocoa implements easy extension.
  • Investigate alternatives to, or possibly in addition to, an enum for storing the fonts and icon names, allowing storage of SVG paths
  • Moving away from drawing the images by using a text-to-image representation
  • Standardizing the @IBDesignable interfaces

If there's anything else that should be touched on, or anyone else has input, I'd be interested to hear it. @chriszielinski had some interesting things in #245 that I may want to fold in.

Since this will be a major version, I'm going to consider breaking changes as acceptable.

@MatrixSenpai
Copy link
Collaborator Author

For pro icons, I'm heavily leaning towards having the user manually install the library and providing detailed documentation on how to do so. There's a lot of stuff in here that can't be included without breaking the privacy entrusted to us by the creators of Font Awesome, and I'd like to avoid conflict as much as possible while still making this library available to those who want to use it

@MatrixSenpai
Copy link
Collaborator Author

My initial take on version 2 has been pushed to the v2.0.0 branch. I have done the following

  • Rebuilt the file structure. I am working towards separating the different components (core, iOS, macOS/iPadOS/Catalyst, etc) into different subspecs. However, I have set up the default subspecs as core + UIKit, so current users will be unaffected
  • Moved away from Fastlane and the Cocoapods structure in favor of a structure used by Swift Package Manager. This provides for a cleaner Xcode workspace (Cocoapods mangles the demo project in by default. Forget that)
  • Added SPM support. Please keep in mind that you will still have to add fonts manually. SPM does not support bundled resources at this time. I have deferred loading fonts for the time being. You may do so using FontBlaster or a similar library.
  • Added a swift tool to run codegen, complete with options (remember to add the Pro repository under the FortAwesome directory, else you will not get Pro fonts!)
  • Added a legacy API, marked as deprecated. For all you out there who like to take your time upgrading once the release is available, you may still use the old APIs. Be aware that there will be warnings
  • Cleaned up a ton of the code and added some extra computed properties to the icons enum. These are also powering the legacy APIs in the background. I've also added those computed properties to instances of the FontAwesomeStyle enum, which means you can either use FontAwesome.allLight or FontAwesomeStyle.light.allIcons.
  • Upped the dependency for iOS from 8.0 > 10.0. There are some UIKit APIs I plan to use. Core may still remain at 8.0, and UIKit may change to a higher version requirement. Mostly it will depend on whether I can find a work-around that won't mangle the code too much.

Please keep in mind this is very, very early stages. Things are subject to change with the new APIs at any time. If I've missed anything legacy, and you don't feel like changing all of your code right now, feel free to leave a comment on this issue or create a new one. I expect to keep legacy APIs for 2-3 minor versions, but not much longer.

@Nodalailama
Copy link

Hi,

How can I pod this branch ?

Doing
pod 'FontAwesome.swift', :git => 'https://github.com/thii/FontAwesome.swift.git', :branch => 'v2.0.0'
give me this spec problem:

[!] Unable to find a specification for 'FontAwesome.swift'.

Cordialement,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants