-
Notifications
You must be signed in to change notification settings - Fork 2
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
Overlap with ndk-context
?
#1
Comments
Hi @MarijnS95, thanks for the question -- I did not know about We didn't use existing crates because this crate is designed to directly support multiple different UI toolkits. Currently only Makepad is supported, but we will shortly support Dioxus (and thus, Tauri since they both use
We do assume a single Activity because that appears to be the model used by Makepad, Dioxus, Tauri, and Xilem, and perhaps others. Note that we do assume and account for the fact that the actual Activity instance may change (when it's destroyed and recreated by the system). Perhaps that model will have to change in the future, but those toolkits do preserve that assumption at the moment. I'm actually quite curious as to why that is the wrong choice. Clearly, a UI toolkit may choose to do things differently, but I'm not sure how and when a second activity object would be used, or why. |
The current design for The current implementations and users of It'd be much better to have the |
i did just find this comment from you, which is an interesting case of potential simultaneous multi-activity existence. Will investigate. |
Perhaps we could layer this crate atop One issue is that Makepad is incredibly sensitive to dependencies (so we wouldn't be able to depend on something like |
For certain platform APIs (e.g., biometric authentication), we need the activity context not the application obj. |
Looking at it in more depth, the way that We also tried to make the interface used by the "middleware crates" (as you call them) and/or app crate as safe, limited, efficient, and standalone as possible, hence why this crate only exposes access to those context states via
Definitely not trying to contribute to divergence. I do want to find a way to consolidate and preserve compatibility across the ecosystem, but it seems tough unless you're willing to accept major redesigns to this crate (which may come at no real benefit?). |
Another option could be for |
Yes, once you get into the territory of opening share dialogs or other "pages within your app" via intents in different "task stacks", you might very well have many activity instances open concurrently that aren't just "because of a reconfig" (when resizing the app or switching to floating / windowed / split mode).
Putting a stop on driving ecosystem divergence, that would do it for me. As mentioned I've long desired to address this issue, and having an actual user - perhaps even collaborator! - would greatly encourage that.
As said the original
We could expose both, is what I'm saying. Certain crates only need "a Re "state setting now allowed": that's exactly what this crate does for the
The versioning problem is specifically why However, you might have also found that I've expressed multiple times that relying on |
tl;dr:
I'd love to collaborate on pulling a generic solution into |
Excellent, let's do it! I'm open to contributing/collaborating on this front for sure. 👍
Great, yes, we'll do that. The
I see, yes that does make sense. I would probably still prefer to expose |
Indeed; given that, I would like to respect that wide usage then, and also become a user as previously mentioned.
Sounds good.
Agreed. I'd be happy to add that even before we have a downstream crate driving the need for it.
Not strictly required, but majorly preferred in our view. Of course that shouldn't be a concern of
That's fair. I had intended to release it closely with Makepad's release cycle, but yeah that is potentially annoying to deal with.
Same, we're on board. How do you propose to proceed -- would you like to take a first crack at it since you already have many design ideas for the next-gen |
we can also discuss on linebender zulip. I will post there. EDIT: posted a new discussion thread here. |
Awesome, glad you're on board @kevinaboos! It'll take me some time to dig through |
No rush whatsoever; feel free to take your time. I can also immediately1 modify Footnotes
|
I added support for |
haven't tested it yet since i don't have quick & easy access to an example app, but i'm trying to get one running for Dioxus |
The ecosystem already has a crate that serves the (as it seems) exact same purpose: https://crates.io/crates/ndk-context. Any reason that isn't used?
Besides, we made the wrong choice in
ndk-context
that anActivity
is a global singleton, and it looks like this crate is making the same mistake.The text was updated successfully, but these errors were encountered: