feat: add Event::Ready

[lemarier]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Docs
• New Binding Issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes. Issue #___
• No

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

[amrbashir]

Seems like we are bit by bit adding new events and making the run() callback similar to tao's EventLoop::run(), should we just move all the events handling there instead of hooks on the builder ? I think it will make it easier for users since they won't have to keep cloning/moving their structs into multiple closures.

ofc removing the hooks are breaking changes so we could keep hooks and also expose all events inside run() and later in tauri 2.0 we could remove one of them based on what users like more or just let them coexist?

[lemarier]

Seems like we are bit by bit adding new events and making the run() callback similar to tao's EventLoop::run(), should we just move all the events handling there instead of hooks on the builder ? I think it will make it easier for users since they won't have to keep cloning/moving their structs into multiple closures.

Yeah ofc this would be great but not sure whats the main plan, but as we may support others runtime, not sure exposing tao event loop directly is safe. So it'll require anyhow some kind of wrapper.

ofc removing the hooks are breaking changes so we could keep hooks and also expose all events inside run() and later in tauri 2.0 we could remove one of them based on what users like more or just let them coexist?

Yes I think you are 100% right here

[amrbashir]

Yeah ofc this would be great but not sure whats the main plan, but as we may support others runtime, not sure exposing tao event loop directly is safe. So it'll require anyhow some kind of wrapper.

No, I didn't mean tao's events directly, I meant exposing tauri's events, instead of splitting some of them on the Builder and some of them inside run()

[lucasfernog]

I think we're ok right now, the other events are not related to the event loop.