[00:00] I really have no idea what's wrong atm but I can look into it [00:01] Next week. [00:02] maybe :) [00:02] sometimes I get stuck on an idea and need to solve it haha [00:03] We should nail down why render isn't idempotent (or why it is in a few cases if it shouldn't be), why you can't unbind/rebind events, ditto data-binding, etc. etc. None of these are clear, and so effort is being spent in blind alleys. [00:03] That's fair. I'll be around this weekend on personal projects, ping me if you come up with things and I can set those aside. [00:05] Makyo: yeah I agree - seems to be the m.o. with viewlets - these use cases keep poping up which it was never intended to be used for [00:05] so we never set out guidelines for these things [00:07] Yeah, that's fair. Maybe if I get some free time one of these weekends, I'll do a thorough documentation of viewlets so we at least know what's there, even if there isn't a pattern. [00:07] We are skirting the line of Views now [00:07] the line is getting thinner and thinner :) [00:14] bcsaller: review and qa done - just one q [00:17] hatch: while I agree, that is the actual system state, if we want to list pending actions in a better way that what notifications should do [00:18] almost all of our actions have real world delays, drawing something else in the meantime isn't really the answer [00:18] its the same principal as with the Dying state we talked about today [00:19] right - but any indicator of the dying state isn't coming for a while, so right now (if the delay is long) the user may click on it and attempt to destroy it, wondering why it's not working [00:19] so while I think what you did is what we want to move towards - it might be a little premature [00:19] I can be convinced otherwise I suppose [00:31] hatch: maybe some improvement to the notification story should happen first [00:31] agreed [00:32] I envision a coloured dot which flys from the users interaction point to the notification bar when there is a notification :)