BlAlarmQueue - split into two classes? Queue : managing the add/remove/sort Scheduler : process the Alarms - alarm/alarmqueue both accessing and check the time "Time now" I would put both checks to, either the alarm OR the queue/scheduler. And don't use "Time now" explicit, if we put this behind a method call, we can easily create alarm queue mocs for unit tests. - readding periodic alarms: shouldn't this be done by the alarm itself - the queue should not care, whether a alarm is periodic. Some alarm examples put the queue into the morphs property dictionary. I could find out why this is necessary. Layout: Box/Column/Row Layout and corresponding cells define a double linked list, we already have a DoubleLinkedList, can we use the DoubleLinkedList instead of reimplmenting this on the layout/cells? Tablelayout: is this "work in progress" or abandoned? Currently it shares much code with the BoxLayout, but it does not look like it is working. Theming: #theme is a property of BlProtoView - isn't this to low level for defining theming support? How would you theme a CircleView or an ImageView? Animation: what are all these "Logics"? animationLogic toLogic stepLogic and steppedLogic(!?) ifLogic .... Is this a software pattern ? I have never seen this before. (For example we use "sortBlock" but not "sortLogic"). How about ValueHolder or good old "Block". And "ifLogic" sounds like a condition, why don't we name it. ... condition? And putting all this "logic" into one animation class scares me. About the class comment syntax: - is this pillar syntax? I think this is difficult to read. Do you use that syntax, because we want to use a pillar as comment text and build a renderer for this or is it to share comments between class comments and the bloc doc book, easily? I can help with documenting the classes but I find it difficult to see which parts of bloc are just tests/proof of concept or are supposed to be in the final version. Maybe I miss the big picture? nicolai