iris commented on pull request iris/iris#15 2026-09-13 21:22:06 -04:00
Run a ui without a window, and test one

why do we have proxy and proxy queue. Can we just re use proxy?

iris suggested changes for iris/iris#15 2026-09-13 20:58:57 -04:00
Run a ui without a window, and test one
iris commented on pull request iris/iris#15 2026-09-13 20:58:57 -04:00
Run a ui without a window, and test one

this is explicitly requesting a redraw. That is not what we want iirc? I remember figuring out with the new code that we could just send an event through the proxy to wake the thread up without making winit think it needs to actually be redrawn. Maybe we could even send events this way? So have a TaskQueue trait that sends the event so you don't need to send + wake separately with winit? unsure how android will work but assuming you can just reuse the trait?

iris commented on pull request iris/iris#15 2026-09-13 20:58:57 -04:00
Run a ui without a window, and test one

this should probably not be called harness / it should be split into multiple files. We're likely going to have many tests that use the harness, and they should be separated into logical groups (maybe like "layout" and "scroll", whatever keeps the files reasonable sizes & easy to understand their purpose) rather than all put in one file.

iris commented on pull request iris/iris#12 2026-09-13 20:39:09 -04:00
Route pointer input per kind, so a scroll falls through a hovered button

why do we need to iterate over self senses? shouldn't they be in active and therefore already in this loop?

iris commented on pull request iris/iris#12 2026-09-13 20:39:09 -04:00
Route pointer input per kind, so a scroll falls through a hovered button

"at the top layer that is under it" please redo this entire comment, it's not very clear. Just be plain and direct, or give a concise example.

iris commented on pull request iris/iris#12 2026-09-13 20:39:09 -04:00
Route pointer input per kind, so a scroll falls through a hovered button

pro tip: you can &mut the Ui::new so you don't have to borrow everywhere

iris commented on pull request iris/iris#12 2026-09-13 20:39:09 -04:00
Route pointer input per kind, so a scroll falls through a hovered button

This comment is also confusing. Should be something more like "true if the sense is action / button related, false if only position related (hover)". May also want to use vocab that's not "momentary", that's a very weird word. You could probably just invert it and call it "position_only" to be more clear. There are other places where this is used so make sure to cover those as well.

iris commented on pull request iris/iris#12 2026-09-13 20:39:09 -04:00
Route pointer input per kind, so a scroll falls through a hovered button

don't bring in new vocab like "hears". "senses" is already exactly the word you'd want here.

iris commented on pull request iris/iris#12 2026-09-13 20:39:09 -04:00
Route pointer input per kind, so a scroll falls through a hovered button

do we actually want to lie about the cursor state? I don't think anything relies on this. Nothing should be trying to detect clicks during hover end, or if something does, it probably wants the actual cursor state?

iris pushed to main at iris/iris 2026-09-13 20:16:17 -04:00
32b10383d8 Rename the Sized widget to SetSize (#14)
iris merged pull request iris/iris#14 2026-09-13 20:16:17 -04:00
Rename the Sized widget to SetSize
iris commented on pull request iris/iris#14 2026-09-13 20:13:50 -04:00
Rename the Sized widget to SetSize

this file is pointless. It obviously works. You don't need to test trivial stuff like this that won't ever break again once the fix is in.

iris suggested changes for iris/iris#14 2026-09-13 20:13:50 -04:00
Rename the Sized widget to SetSize
iris commented on pull request iris/iris#12 2026-09-13 20:06:24 -04:00
Route pointer input per kind, so a scroll falls through a hovered button

don't worry about "top most" within a layer or widget. In fact, senses should only be blocked for lower layers. Senses on the same layer should not block each other at all.

iris commented on pull request iris/iris#12 2026-09-13 20:06:24 -04:00
Route pointer input per kind, so a scroll falls through a hovered button

what is this used for? does it need to exist?

iris commented on pull request iris/iris#12 2026-09-13 20:06:24 -04:00
Route pointer input per kind, so a scroll falls through a hovered button

I don't like this fix. Instead senses should have a proper fall through mechanism that doesn't require taking them. Iirc there was something like that in the new version but I could be wrong. You shouldn't have to iterate senses like this.