Fork me on GitHub
#humbleui
<
2023-01-01
>
Daniel Gerson14:01:24

Happy new year! I was wondering what the way is to check if a label or other control is being displayed. I have lazily processed data, and as I scroll down I'd like to further process items. In my case there is temporary (lower res) data displayed initially, so sizes don't change. I guess a percentage of scroll info could work, but it would then be nice to be able to work out exactly what controls this relates to.

Niki20:01:52

Not yet, but I plan to have something like that

Daniel Gerson11:01:13

I'm happy to implement it, but would like to get your thoughts on the right model. Is it events to child controls? Or would you pass in a *state var to subscribe to it's state? Latter seems more flexible.

Niki13:01:39

I was thinking about something more fundamental, like passing viewport to the draw and transform it in case of e.g. clip/scroll. If visible viewport is empty, don’t draw. Just scroll feels like too specific, although it’s probably the most common use-case together with column

Daniel Gerson08:01:40

I would like to support the added feature that some number of controls below the visible area could be notified to be improved. In fact I'd like the work associated with the updating of the controls to run in a separate thread, and thus a wider view of pending work be available than a child control specific one. Assuming the work takes some time to do, the user is unaware of this as they scroll down! Presumably this doesn't work with passing the viewport in? On a side note I can't see a viewport object in the code, only the canvas & relevant rect sizes, therefore how are you using the term here? Presumably not the glViewport?

Niki17:01:25

That’s because it’s not implemented yet :)

👍 2
Niki17:01:52

For rendering ahead you’d probably need some custom solution though, it doesn’t sound like something that is required in the core

Daniel Gerson15:02:43

So I did it the other way around. The IComponent.-draw already passes the "viewport". It's just that vscrollbreaks this contract by passing an enlarged rect as if it assumes it is all drawn. So I changed my version of extra/vscroll to honour the contract, and instead I made the offsetproperty move one level deeper. Then my extra/OffsetIndexableColumnknows how to draw its children (and notify a fn about the last one drawn) based on its own offset property. Moving offset to a child of extra/vscrollmeans the extra/vscrollbarcreation function is now:

(defn vscrollbar [child]
  (let [nesting (if (satisfies? IOffset child)
                  (-> child vscroll)
                  (-> child trans-offset vscroll))]
    (scroll/map->VScrollbar
     {:child      nesting
      :fill-track (paint/fill 0x10000000)
      :fill-thumb (paint/fill 0x60000000)})))
trans-offset being a wrapper ui class that allows a non IOffset component like Column to be used instead. My stuff is still subject to change while I hook it all up.

Daniel Gerson15:02:16

(I probably could have just tested for an :offsetproperty instead of creating IOffsetbut this was my first foray into deftype/deftype+and so a lot of learning and experimentation later...)