This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
I don't know if you prefer this feedback elsewhere, but this snippet from the tutorial:
(let [elem (ui/on ;; return nil for any mouse-down event :mouse-down (fn [_] nil) (ui/button "Big Red Button" (fn  [[:self-destruct!]])))] (ui/mouse-down elem [20 20])) >>> ()
I've found the root cause. There's been some on going work to 1. improve event performance 2. clarify some edge cases There's still some design work left to figure out the best option. This bug should be fixed as those changes are integrated. I've removed the example for now. Thanks for pointing it out!
I've fixed this issue and it will be included in the next release. thanks again for the report!
(as a minor nitpick, the next exampe evaluates to
(), but I don't suppose that matters much?)
for how I've been using it, it hasn't mattered, but I should probably think about what the "right" answer should be.
a more general comment on the tutorial: it seems to assume that reagent-like atom-based reactive behavior is well-known to readers, which is perhaps fair in Clojureland. but the simple-ugly-checkbock-without-using-any-framework example made me wonder how does membrane actually perform the update. it seems to be rerunning the thunk we pass to
skia/run, but how does it know when to do that? I guess on every event? so if I update the atom programmatically without having any events triggered I won't get any refresh? what gets rerendered? the whole window, I guess?
I also noticed that there is some lag between the time I click and I see updates in the screen, especially the very first click
I test almost exclusively on mac osx. I wonder if it's some code that's not good for linux or something else.
which makes me wonder a bit about what overhead is involved in event handling and response
this is feedback is really helpful. one of the challenges of this project is that it has a pretty large surface area. to make a ui, you need graphics, state management, and supporting documentation. there's quite a few areas where it's still running on the "simplest implementation possible"
yes, it the window will update on every event, or every 3 seconds. generally, speaking the whole window gets updated. there are a few optimizations to reduce draws, but very few at the moment. there is a way force the window to refresh, but it's not documented at the moment
another bit that is not explicitly explained is that when testing out the component definitions leading to the final example plain clojure data is used, but in the final example itself we pass an atom to the component. somehow the framework seems to handle that case especially. it would be nice if the tutorial briefly explained (not only demonstrated) the semantics of that
i'm currently in the process of documenting the principles that underly everything. hopefully, the documentation should improve noticeably over the next few weeks
is the delay apparent in the example code, or are there changes where the state might not have been updated before the function returns?
the delay is noticeable in the tutorial example code as is, but only if I cilck ~quickly after launching the window. if I wait a few seconds and then click then I notice no delay
I think I'm more likely to get a small delay if I press and hold the mouse button (although the code seems to be clearly reacting to presses, not press-release sequences)
from a performance perspective, I've done optimizations as I run into bottlenecks and I'm currently building medium size apps that feel pretty responsive, but there's still lots of optimizations that haven't been implemented yet
as a phrasing nit, I had to read this sentence a few times before I understood it: "To run a component, simply call your implementation's run function with ...". In retrospect, that clearly means the implementation I chose (e.g., skia), but initially it seemed to refer to something I wrote
hmmm, a better wording might be:
> To run a component, simply call the backend's (eg. skia)
run function with...