Ok so to clarify what I want with Spec:
- move LayoutFrame outside of Morphic. Now I'm not sure that spec
should depend on it, may be.
- LayoutFrame is a bad name for a transformation specification.
- I do not think that an Array is good but I do not think that using
two rectangles is good either
Do we think that (0@0 corner: 1@1). (0@22 corner: 0@0). is
readable?
No it looks quite bad and as bad as #(0 0 1 1 0 22 0 0)
Probably we should have
layout {LayoutFrame rightOffset: 22) instead of
specifying everything when this is not needed
especially since now LayoutFrame new is equivalent to
(0@0 corner: 1@1). (0@00 corner: 0@0)
- Finally we should not edit by hand such methods and esteban will work
on that.
- We should
- rethink the contents of spec methods they should cover
structural information such color,
defaultExtent; minimalExtent:…and this should be modular (it is
already).
Each kind of spec should be responsible of declaring what it
needs to create its visual component.
- we should be able to mix structural specification with DSL
driven ones.
RIght now when you use the dsl you cannot specify structural
information at the composite level (I may be wrong)
- rethink if we use a class for each specific spec elements so
that we can build nice visitors
I do not remember how this is done in Spec. In VW this is like
that (but visitors are not used or I missed them).
- revisit the interpreter because it is not modular.
right now this is difficult to extend it and it would be better
that the interpreter delegates to
each of the spec elements their interpretation.
Have a look at the method interpretASpec: aPresenter
- rethink the asArray methods. You will see that they implement
some spec layout algorithms that are not
independent of Morphic and quite complex (note that we
simplified these methods). So we should understand
and see because I have the impression that they are outside of
Spec more on layout in general.
- with igor we fixed fractions:offsets because it creates rectangles
with negative height and width.
=> this brings some problems when we want to fix intersect: and this is
really important
because the intersection of disjoint rectangles is not a negative ones.
Right now this works
because the primitives are discarding call with negative arguments but
this is doomed by construction.
Now we could have ignored Spec and let benjamin do the dirty work and
we would have waited
to be able to go to the next step. So we took our energy and fixed Spec
too which I think
is normal because if this is part of the infrastructure then we should
maintain it. But we are not expert on Spec
and it would have been more fun to do it with Ben. Now we just did what
we think is good and
during holidays is one of the few moment of calm I can have…. so we did
it at that time because of that.
Stef
> On 8 January 2013 18:12, Sean P. DeNigris <[email protected]> wrote:
>> Benjamin Van Ryseghem-2 wrote
>>> Why using a meaningless array when we could use object ?
>>
>> +1. This seems hard to use/understand. If we don't want to depend on
>> Morphic, let Spec define its own intention revealing messages.
>
> Or pull LayoutFrame out into a separate package. That Morphic depends
> on that new package doesn't matter at all; what matters is that
> LayoutFrame doesn't depend on Morphic. LayoutFrame's a nice simple
> class.
>
> frank
>
