Skip to content

Next Major Version Discussion #252

Open
Open
Next Major Version Discussion#252
Assignees
MatrixSenpai
Labels
discussion

Description

@MatrixSenpai
MatrixSenpai
opened on Apr 21, 2020

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

Activity

  1. MatrixSenpai
    self-assigned this
    on Apr 21, 2020
  2. MatrixSenpai
    added
    discussion
    on Apr 21, 2020
  3. MatrixSenpai
    pinned this issue on Apr 21, 2020
  4. MatrixSenpai
    changed the title [-]Using Pro Fonts in this library[/-] [+]Next Major Version Discussion[/+] on Apr 28, 2020

  5. MatrixSenpai commented on Apr 28, 2020

    @MatrixSenpai
    MatrixSenpai
    on Apr 28, 2020
    CollaboratorAuthor

    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.

  6. MatrixSenpai commented on Apr 28, 2020

    @MatrixSenpai
    MatrixSenpai
    on Apr 28, 2020
    CollaboratorAuthor

    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

  7. MatrixSenpai commented on May 20, 2020

    @MatrixSenpai
    MatrixSenpai
    on May 20, 2020
    CollaboratorAuthor

    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.

  8. Nodalailama commented on Nov 21, 2021

    @Nodalailama
    Nodalailama
    on Nov 21, 2021

    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

Metadata

Metadata

Assignees

Labels

discussion

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions