Is there anything (at all) to gain in my continuing to use
ROMondrianViewBuilder versus "native" Roassal?
Is ROMondrianViewBuilder "just" for backward compatability to ease the
transition and draw people into the new system?
Or... is there stuff that ROMondrianViewBuilder does better than
"native" Roassal - in terms of conciseness, ease of use, flexibility,
access to layouts, features, etc...
I am trying to determine whether putting effort into the perhaps easier
step of going from Mondrian to ROMondrianViewBuilder may be wasted
leaving me missing out on any new power of Roassal, or require more
effort later to rework for native Roassal.
You may have gone over this before, but how do the purpose and
architecture of the two differ?
cheers -ben
Just recording a bit of my learning the internals of Roassal, since it
helps me flesh out my understanding.
[ROShape>>removeShape:] does not have a test to reference for my
understanding of this, but it appears to not work as expected. For
example in workspace...
b := ROBox new.
c := ROCircle new.
b addLast: c.
b removeShape: ROCircle.
b inspect
results in a linked list of: aROBoxShape --> aROCircleShape -->
aROChildrenShape.
Actually the semantics of [removeShape:] seem problematic. What should
be the result of...
b := ROBox new.
b removeShape: ROBox.
b inspect.
I would guess that 'b' should hold aROChildrenShape, except you can't
change the value of 'b' from inside the [removeShape:] method. (In my
limited knowledge of 'slots', I wonder if this is something they might
help with.) I am relying on the guess that you could have
aROChildrenShape as the only shape on an element, for subviews without a
border, but could you clarify this.
Naively I thought to just try... removeShape: aShapeClass
^ (self isKindOf: aShapeClass)
ifTrue: [ next become: next next ]
ifFalse: [ next removeShape: aShapeClass ]
but the danger of #become hit me and locked my image.
btw, something else just while I am feeling evil, what should happen
with the following...
b := ROBox new.
b removeShape: ROChildrenShape.
b inspect.
cheers -ben
Hi everybody,
is there a Pharo port of Code City?
I am wondering because the use of VisualWorks Smalltalk and the
license restrictions that come with it make it impossible to use Code
City in a commercial setting (if I understand it right).
Cheers,
Torben
Just recording a bit of my learning the internals of Roassal, since it
helps me flesh out my understanding.
At first glance looking at [ROShape>>addLast:] this seemed to
recursively call itself with no exit-condition, but then I noticed its
ivar 'next' is initialized to ROChildrenShape this provides the exit
condition inherited from RONullShape. Adding a shape replaces this
ROChildrenShape in 'next', but the new shape itself has a
ROChildrenShape in its 'next' .
I haven't got as far looking at ROChildrenShape yet, but briefly thought
it might be a container holding other shapes, but then actually I think
it is the ROElements ivar 'elements' that is the container of subview
nodes - and that ROChildrenShape just stores how to draw the subview nodes.
I guess it is the lack of the [drawOn:For:] method that distinguishes
between abstract and concrete ROShape classes. By the way, what is the
design decision of leaving [ROShape>>drawOn:For] blank rather than using
[self subclassResponsibility] ?
So, just to confirm my understanding, perhaps the following or similar
would be useful as a comment on ROShape>>addLast:
"Instance variable 'next' must be a RONullShape to provide the exit
condition of this recursive call. This is ensured by instance
initialization"
cheers -ben
I was browsing Roassal looking for how mouse-overs are handled, and
bumped into the method ROBeginingAnimation>>isOver, and I was
momentarily confused by what "over" would mean in this context. Without
knowing the whole architecture, I am thinking that perhaps a better
method name would be 'isComplete'. In a highly GUI oriented system,
"over" has too many meanings without diving into the code.
If that is reasonable, but I distraction from other work, I could
implement and submit the change. The method is referenced from five
methods and three tests.
cheers -ben
Hello all,
Just wanted to know if the Windows VM file (Squeak.exe) in one-click Moose
package is the latest version of the VM (in image-folder/Contents/Windows)?
Can I know the source of the vm because I remember downloading one
(Cog.exe) that worked better?
tx,
Usman
Hi everybody,
as I'm new to this list I just wanted to say hello.
I'm quite new to Moose and completely new to Smalltalk - so please
forgive any newbie questions :-)
I came to Moose via CodeCity, and I believe it's a powerful platform,
thus I'm eager to learn more about it. I'm especially interested in
using Moose / CodeCity in a commercial setting, e.g. in the context of
architecture assessments and code reviews that we are doing for
customers. Actually I recently used Moose in such a context, but could
not get quite to the results I wanted to. Not because of Moose, but
rather because I'm not familiar with the Smalltalk environment and
especially Mondrian painting yet...
Today I found this mailing list from which I believe it's a good
source for information and knowledge exchange.
So, "Hello!" :-)
Cheers,
Torben