SqMondrian

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

SqMondrian

Alexandre Bergel-4
Hi All,

I was wondering why is there a method originFor: in FormsBuilder. In  
VW there is none. Why the builder should know about the bounds of the  
element to display? I always though the shape was in charge of it.

Something else, both in Squeak and VW we have the following method:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
FormsBuilder>>at: aX and: aY
        "Utility method that makes other methods easier to read."
       
        ^self components
                select: [:component | component gridX = aX and: [component gridY =  
aY]]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Is there a reason to not store the components in a matrix ? One reason  
that I see, is that one could have a large compound contains only few  
elements in it. But still, I find that strange.

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SqMondrian

Tudor Girba-3
Hi Alex,

I guess this mail was supposed to go to moose-dev, too :).

> I was wondering why is there a method originFor: in FormsBuilder. In
> VW there is none. Why the builder should know about the bounds of the
> element to display? I always though the shape was in charge of it.

The method's name is wrong. The *For: methods take a Figure as an  
argument.

In our case it should be originOf: because it computes the origin of a  
shape inside the context of the form.

> Something else, both in Squeak and VW we have the following method:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> FormsBuilder>>at: aX and: aY
> "Utility method that makes other methods easier to read."
>
> ^self components
> select: [:component | component gridX = aX and: [component gridY =
> aY]]
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Is there a reason to not store the components in a matrix ? One reason
> that I see, is that one could have a large compound contains only few
> elements in it. But still, I find that strange.

You could store it in a matrix.

Cheers,
Doru



> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
www.tudorgirba.com

"Problem solving should be concentrated on describing
the problem in a way that is relevant for the solution."




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project