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

Swing and JavaFX FontIcons no longer work in same application as of 12.0.0 #127

Closed
eric-upchurch opened this issue Dec 21, 2020 · 3 comments
Assignees
Labels
Milestone

Comments

@eric-upchurch
Copy link

With versions 11.5.0 and previous, you could utilize both Swing and JavaFX Ikonli FontIcons in the same application without problems, and easily convert between them by retrieval of the Ikon.getIconCode() and passing it into the respective FontIcon.of() methods of either the Swing or JavaFX FontIcon classes.

With 12.0.0, once you use either a JavaFX or Swing FontIcon, the IkonHandlers for each will return the font class of the first used FontIcon type. Using the other (e.g. using JavaFX and then Swing) will cause a CastClassException because the IkonResolver for each type will return the same Font class - if you use Swing FontIcon first, it will return java.awt.Font; if you use JavaFX FontIcon first, it will return javafx.scene.text.Font. This prevents you from using both JavaFX and Swing FontIcons within the same application.

This can be demonstrated with the following code segment:

public class IkonliFxWithSwing {
  public static void main(String[] args) {
    org.kordamp.ikonli.swing.FontIcon swingIcon = org.kordamp.ikonli.swing.FontIcon.of(Ikonli.NONE);
    org.kordamp.ikonli.javafx.FontIcon fxIcon = org.kordamp.ikonli.javafx.FontIcon.of(Ikonli.NONE);

    IkonHandler fxHandler = org.kordamp.ikonli.javafx.IkonResolver.getInstance().resolve(fxIcon.getIconCode().getDescription()); // change to resolveIkonHandler() for Ikonli 11.5.0
    System.out.println("JavaFX Font: " + fxHandler.getFont().getClass().getName() + " -> " + fxHandler.getFont());

    IkonHandler swingHandler = org.kordamp.ikonli.swing.IkonResolver.getInstance().resolve(swingIcon.getIkon().getDescription());
    System.out.println("Swing Font: " + swingHandler.getFont().getClass().getName() + " -> " + swingHandler.getFont());
  }
}
@aalmiray
Copy link
Collaborator

aalmiray commented Dec 21, 2020

Hmm I believe Ikonli was not designed to have both Swing and JavaFX icons resolved in the same application. It might have worked like that by mistake. This being said, I'll see if it's possible to officially support this setup.

@eric-upchurch
Copy link
Author

Thanks for looking into it! If possible, it would great to have that officially supported for our use case since we still have some components that require Swing in an otherwise fully JavaFX UI.

@aalmiray
Copy link
Collaborator

FWIW the problem stems from c78b2d2 where static members that were previously private to each IkonResolver type were pushed upward to a common ancestor. As I said, it was pure coincidence the behavior you seek actually worked, I know now how to fix it so that it works for good 😄

@aalmiray aalmiray self-assigned this Dec 21, 2020
@aalmiray aalmiray added the Bug label Dec 21, 2020
@aalmiray aalmiray added this to the 12.0.1 milestone Dec 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants