DRAFT: 233 split winit,gpu from core #290
Conversation
except of static lifetime
except of static lifetime
Codecov Report
@@ Coverage Diff @@
## master #290 +/- ##
==========================================
- Coverage 72.30% 69.15% -3.15%
==========================================
Files 161 193 +32
Lines 19032 20010 +978
==========================================
+ Hits 13761 13838 +77
- Misses 5271 6172 +901
... and 2 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
and implement PartialEq for PointerId
core/src/events/dispatcher.rs
Outdated
| let pos = position.to_logical::<f32>(wnd_factor); | ||
| self.cursor_move_to(Point::new(pos.x, pos.y), tree) | ||
| let logical_pos = | ||
| ScaleToLogic::new(1.0 / wnd_factor as f32).transform_point(position.cast()); |
There was a problem hiding this comment.
the core window does not need ScaleToLogic and window_factor, wnd_factor should transparent to the core window. The s
hell window converts all positions to the logic axis before passing it to the core window.
There was a problem hiding this comment.
Does this mean the distinction between physical and logical should not exist at all within Ribir, but always be resolved in ribir_winit? Or did you mean just this place?
The distinction comes mostly from the part of ribir_painter that I moved out to ribir_geometry.
There was a problem hiding this comment.
it should all resolve in ribir_winit, ribir_app need to know it to transform the painter.
There was a problem hiding this comment.
Logic means scale, not axis, right?
ribir_painter used DeviceSize (physic)
I'm not sure how this can work. When everything is converted to logic before passed to the core window, does this need to converted to physics before passed to painter? That doesn't seem right to me.
Logic values use float. I'm not sure how that works with painting.
Can you please shed some light on that?
There was a problem hiding this comment.
Now, it's used as a scale. Logically axis means Ribir will support a Transform2D to convert the axis from the device, for example, embedding Ribir in another UI system, at least needing translation and scale.
There was a problem hiding this comment.
does this need to converted to physics before passed to painter?
You don't need to do it. When constructing a painter we pass a scale or Transform matrix to it, the painter will do it by itself.
|
@zoechi I review it all over and looks great. Thanks!
|
|
@M-Adoo Thanks for your feedback. I still have troubles seeing what the end result should look like. |
|
If we abstract the window, we needn't change the application code, we can just use the feature config to switch Application::<MyShellWindow>::run()Our target is not to reuse the code in |
|
Ok, I guess I understand now what you mean. |
In which crate should this happen? The crate where this happens needs to have a dependency to ribir_winit and all used alternatives. |
In |
cd ribir cargo run --example todo_mvp -F winit,wgpu_gl or cd ribir cargo run --example todo_mvp -F crossterm
|
I'm still not sure about the direction for the ShellWindow API. I added a dummy Crossterm backend implementation so that I have something concrete to develop towards. |
|
@zoechi For ShellWindow and EventLoop, they are almost always in pairs.
|
In the case of Winit, EventLoop seems to be provided. It's not clear to me where or how I should prepare an API for it.
It appears to me |
No, core window have its window config and need to pass to shell window to display. I try to define some APIs for you and feel free to rename and adjust it. pub trait Eventloop {
type SW: ShellWindow;
// start the event loop, dispatch the events to shell windows.
fn exec(&mut self, app: &mut Application);
fn stop(&mut self);
fn exit(self);
}Application or impl ribir_core::Window {
pub fn resize(&mut self, size: Size) {
if let Some(shell) = self.shell_wnd.as_ref() {
shell.resize(size);
}
}
pub fn shell_wnd(&self) -> Option<&dyn ShellWindow> {
}
...
}
pub trait ShellWindow {
/// construct a shell window for core window.
fn constructor(core_wnd: &core::Window) -> Self;
fn resize(&mut self, size: Size);
fn set_title(&mut self, size: Size);
...
}Core window own an |
|
I hope to be able to continue soon, but I'll close for now. |
fixes #233
follow-up to #273
This still needs cleanup.
I was thinking about the suggested ShellWindow,
but I'a quite lost on that topic.
Perhaps you can have a look and provide some more feedback this topic and also to the general direction in this PR.
I made an attempt at Traits for Application, WindowBuilder, EventLoop and thought about how to put this together into a ShellWindow somehow, but it didn't make too much sense to me.
These things only contain Winit-specific code and don't interact with the rest of the code. Creating some abstraction that would match the same structure for Winit and possible Winit-alternatives seems rather limiting instead of gaining any flexibilty or improved dev experience.
Perhaps you can shed some more light on that.