Labels: Type-Defect Priority-Medium Component-Glamour
New issue 701 by alexandr...(a)gmail.com: Cut and Paste do not update a
Regarding copy paste, indeed it seems that pasting a text does not update
the port. Please open a ticket.
I found another strange behavior, likely to be a bug.
| browser |
browser := GLMFinder new.
act: [:prez :v | prez text inspect ] on: $i entitled: 'Inspect'.
browser openOn: 'hello world'
If you type something and press cmd-i then you open an inspector on what
you have typed.
Now, do a cut and paste in the textpane, and press cmd-i. You have an
inspector on 'hello world', no matter what you have cut&pasted.
Labels: Type-Defect Priority-Medium
New issue 501 by alexandr...(a)gmail.com: Cache independence
The core of Mondrian is not independent of the cache implementation. The
logic of Mondrian rely on the cache to implement its semantics. This is
"Answer the bounds of the receiver."
"the bounds is has an absolute origin"
"Note that the bounds computed above, may have (and it is likely to) a
different origin. The reason is that the layout is in charge to position
the nodes properly"
| basicBounds |
boundsCache ifNotNil: [ ^ boundsCache ].
"We check if the shape if present"
self shapeBoundsAt: self shape ifPresent: [ :b | ^ boundsCache := b ].
basicBounds := self shape computeBoundsFor: self.
self shapeBoundsAt: self shape put: basicBounds.
^ boundsCache := basicBounds
absoluteBoundsCache ifNil: [ ^ self ].
absoluteBoundsCache := absoluteBoundsCache translateBy: aPoint
Thanks to Santiago Vidal for pointing this out!
Labels: Type-Defect Priority-Medium Component-Spy
New issue 503 by alexandr...(a)gmail.com: Abstract classes and Hapao
Gaëtan le Brun suggested to remove abstract classes before running the test
This makes sense
I'm looking to improve current implementation, and maybe you can help me.
The current procedure is based in a custom serialization of each
MooseElement. It's inspired on MSE, I describe this with the following
(MooseModel meta descriptionOf: aMooseElement class) allAttributes
do: [ :anAttribute |
| values |
values := anAttribute getFrom: aMooseElement.
(self shouldIgnore: anAttribute withAll: values)
ifFalse: [ self serialize: anAttribute withAll: values ] ].
shouldIgnore: anAttribute withAll: values
^ values isEmpty or: [
anAttribute isDerived or: [
anAttribute type == FM3MetaDescription boolean and: [
values size == 1 and: [
values first == false ]]]]
The advantage of serializing the MooseElements in this way (and not just as
a normal object) is to avoid storing unnecessary stuff that aMooseElement
It's a disadvantage using FM3PropertyDescription>>getFrom: (and then to
import, FM3PropertyDescription>>setOn:values:) which ends sending #perform:
of the corresponding accessor selector. It'd be better to use #instVarAt:
(and #instVarAt:put:) as Fuel normally does.
I hope I've been clear enough to explain up to this point. Now my question:
Do you think Fuel can do something on each MooseElement like
- clean up some unnecessary references
- declare some instance variables as transient
- if it's not good idea to modify the elements, create a method like
MooseElement>>copyWithoutDerivedValues, and so actually serialize such copy
instead of the original element
- any other
and thus, serialize the MooseElements as normal Fuel objects, removing the
I'll be happy to receive some help from Moose and Fame experts!
Thanks in advance.
Labels: Type-Defect Priority-Medium
New issue 644 by cy.delau...(a)gmail.com: A fly by help to show each time the
source code of an entity
Maybe it would be interesting when navigating in moose, to always have a
fly by help that show the source code of an element
Labels: Type-Enhancement Priority-Medium Component-Glamour
New issue 582 by tudor.gi...(a)gmail.com: Watcher support in Glamour
Like we now have a statusbar, we should also have a detailed preview shown
in a floating Watcher window. The behavior would be similar to Quick Look