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

Break dependency from fj-window to fj-host #1736

Closed
hannobraun opened this issue Mar 28, 2023 · 1 comment
Closed

Break dependency from fj-window to fj-host #1736

hannobraun opened this issue Mar 28, 2023 · 1 comment
Labels
type: feature New features and improvements to existing features

Comments

@hannobraun
Copy link
Owner

fj-window is the Fornjot library that uses winit to provide an event loop and pull much of the Fornjot ecosystem together. It is the main dependency on fj-app. fj-host is the library that loads models and is responsible for their interaction.

It is totally reasonable to want to build an app with fj-window, but at the same time not wanting to be bound to fj-host, for example to experiment with different approaches to loading models, or with supporting different programming languages for models.

Currently, this is not possible, as fj-window has a hard dependency on fj-host. I think it would be better to replace the dependency with a generalized interface, that can be used for alternative implementations. I haven't looked into the details of what would required for that yet, but I think it would boil down to passing the interface for fj-host into fj-window's run method.

I can see two scenarios for implementing this interface:

  • Use something rather simple, like a channel from crossbeam-channel. I suspect that this might be a bit too simplistic.
  • Define a custom trait in fj-interop and implement that trait in fj-host.

It would also be possible to achieve the same goal in a different way, by instead creating traits inside fj-host to make loading/evaluating/updating models pluggable behaviors.

@hannobraun hannobraun added type: feature New features and improvements to existing features topic: ecosystem labels Mar 28, 2023
@hannobraun
Copy link
Owner Author

This issue is no longer applicable. The affected code has been removed. See A New Direction for context.

@hannobraun hannobraun closed this as not planned Won't fix, can't repro, duplicate, stale May 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature New features and improvements to existing features
Projects
None yet
Development

No branches or pull requests

1 participant