Files
iris/TODO
T

41 lines
2.2 KiB
Plaintext

images
settings (sampler)
consider typed TextureHandle<T> variants for distinct texture uses
WidgetRef<W> or smth instead of Id
enum that's either an Id or an actual concrete instance of W
painter takes them in instead of (or in addition to) id
then type wrapper widgets to contain them
allows for compile time optimization if a widget wrapper's inner is known at compile time
and the id of inner is not needed anywhere
maybe introduce InnerWidget trait to allow for editors to expose & modify inner type
maybe could also store a parent widget and keep using InnerWidget trait? unsure if possible
vecs for each widget type?
POTENTIAL BUG: closures that store IDs will not decrement the id!!! need to not increment id if moved into closure somehow??? wait no, need to decrement ID every time an event fn is added...... only if the id is used in it..??
transforms on a move entry (scale + rotation)
an entry is a translation today; composing through one scales the rel
part and passes px through untouched, so fixed-size content and glyphs
do not follow a shortened entry
want a real transform per entry, resolved in resolve_move the way the
translation already is, so a whole subtree transforms with one buffer
write and no redraw
wanted for compose-style stretch at the end of a scroll area, and for
rotation generally
a prepare stage on Event, so Data has no placeholder field
run_sensors builds one CursorData per widget and has to put something in
`sense` before anything knows which sense matched, so it writes
CursorSense::Hovering and says in place that it means nothing;
should_run then clones the whole thing to overwrite that one field
the state is representable only because the type lets the caller say it:
what the caller supplies and what matching adds are two different things
wearing one struct
the awkward part is doing it without the generics getting annoying --
Data<'a> is already a GAT with a default, and splitting it in two adds
another associated type to every Event impl for the sake of one field
(Bryan, 2026-09-20; low priority, he wants a good answer rather than a
quick one)