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