Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 846 by google....(a)ben.coman.com.au: Roassal Easel Find... button
http://code.google.com/p/moose-technology/issues/detail?id=846
With the following steps in Roassal.AlexandreBergel.320
1. World > Tools > Roassal Easel
2. <Example> > ROExample > #basic > lines
3. <Find...> > Node1 > Node2
produces an "Error: not found" from RONullShape.
I am guessing this should be working in this example.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 843 by google....(a)ben.coman.com.au: ROLightlyHighlightable drains
element colour
http://code.google.com/p/moose-technology/issues/detail?id=843
The following code snippet results in the attached image, showing that
ROLightlyHighlightable drains the original colour from el2 - leaving it
drab and dreary. I think we need to liven up the party for poor old el2,
and give him back his colour.
--------------------
el1 := (ROElement on: 1) height: 50; width:50.
el1 + (ROCircle color: Color lightGreen).
el2 := (ROElement on: 1) height: 50; width:50.
el2 + (ROCircle color: Color lightGreen) @ ROLightlyHighlightable.
rawView := ROView new @ RODraggable.
rawView add: el1.
rawView add: el2.
ROHorizontalLineLayout on: rawView elements.
rawView open.
--------------------
Attachments:
ROLightlyHighlightable-drains-colour-from-element.png 3.6 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 842 by google....(a)ben.coman.com.au: ROTranslatingShape mouse
hotspot mis-alignment
http://code.google.com/p/moose-technology/issues/detail?id=842
Fix attached related to the following mail-posts
Also attached are before and after snapshots from
ROExample>>nestingTranslate.
Ben Coman wrote:
> I was trying to apply ROTranslatingShape to produce a label sitting above
> the
> children nodes. To understand it better how to get what I
> need, I made ROExample>>nestingTranslate to show a permutation of the
> order
> the shapes can be applied. I have attached a screen snapshot and fileout
> for
> this. The case I am particularly interested in is el3.
> The 'el0' case is the reference without any ROTranslatingShape.
> When running the example hover near and over the inner elements to view
> the
> misalignment of the mouse hotspot. I have marked the approximate offset in
> green in the snapshot.
> I notice that the existing call chain goes...
> ROView>>localElementAt:
> ROElement>>elementAt:
> ROElement>>contains:
> ROElemenet>>bounds
> ROShape>>extentFor: (union of extent of each shape)
> It seems to me the hotspot misalignment is related to the translation
> being
> applied at the shape draw level whereas the #contains: checking is done
> at the
> element level. This relies on the union of the shape extents to set the
> element bounds, but I can't see how that extent union could be modified to
> account for the translation - particular in the case of a negative
> translation
> since extents throw away information
> about any negative offset.
> So I thought perhaps that the element #contains: checking needs might be
> better chained through the shaped, so that the translation
> could be applied similar to ROTranslatingShape>>chainedDrawOn:for: and
> that
> this would not cause any/much additional computation since all the shapes
> were
> being cycled through anyway for #extentFor:
> Something like...
> ROView>>localElementAt:
> ROElement>>elementAt:
> ROElement>>contains:
> ROShape>>chainedContains:For: (for each shape)
You can see in all case el1 to el8, the child elements have shifted in
relation
to el0.
However the hotspot remains aligned with the location in el0.
I think part of the problem is that ROChildrenShape is a
ROAbstractEndingShape
and is always at the end of the line - so the translation is applied to the
children elements.
Whereas it might work better if the position of the child elements was not
affected by ROTranslatingShape, such that it becomes the reference for the
position of any other translated shapes.
This would require ROChildrenShape be always the first shape of an element,
rather than always be the last shape.
--------------------
The following code snippet...
el := ROElement on: 1.
(el + ROBorder + ROTranslatingShape + ROLabel ) inspect.
produces shapes chained in order of:
ROLabel-->ROTranslatingShape-->ROBorder-->ROChildrenShape.
which seems reversed from what I would intuitively expect reading the code
left
to right.
I think ideally the shape chain would be:
ROChildrenShape-->ROBorder-->ROTranslatingShape-->ROLabel-->RONullShape
Otherwise as in el1 you can see the position of the label is the same as
el0,
since the label has actually been drawn first prior to the translation, and
instead the translation is applied to the border and child elements, the
latter
of which affects the mouse hotspot.
Attachments:
Roassal-BenComan.310.mcz 242 KB
ROTranslatingShape-permutations-mouse-hotspot-broken.png 33.2 KB
ROTranslatingShape-permutations-mouse-hotspot-fixed.png 29.8 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 841 by hephster(a)gmail.com: Roassal: ROPopup: Text not visible
http://code.google.com/p/moose-technology/issues/detail?id=841
See the example in Roassal Easel: Interaction -> Popup.
The popup is always gray with no text visible.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 840 by google....(a)ben.coman.com.au: ROCircle border only
http://code.google.com/p/moose-technology/issues/detail?id=840
Could you include in Roassal the ability to have a non-filled circle. See
attached.
Attachments:
ROCircle.1.cs 1.4 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 839 by google....(a)ben.coman.com.au: ROCenteredLabel
http://code.google.com/p/moose-technology/issues/detail?id=839
I required text to be centered within a circle, so I created
ROCenteredLabel. I think it would be generally useful. Would you consider
adding it to Roassal?
Attachments:
ROCenteredLabel-drawOnfor.st 1.0 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 828 by google....(a)ben.coman.com.au: [Roassal] ROMorph>>mouseOver:
evt
http://code.google.com/p/moose-technology/issues/detail?id=828
Didn't bump into this as a runtime error, but browsing the code noticed
that ROMorph>>mouseOver:evt calls super>>mouseOver: which does not exist.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 825 by google....(a)ben.coman.com.au: Roassal extents of text does
not work with a tab character
http://code.google.com/p/moose-technology/issues/detail?id=825
Referring to the following line in ROMondrianExample>>labeledRectangleOn:
view node: ' With rectangle'.
if I use the <space> key to insert before the 'W', then the outside border
resizes fine. However if I use the <tab> key before the 'W', then the
border does not size properly and cuts over the text.
This is with ConfigurationOfRoassal.491.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 824 by google....(a)ben.coman.com.au: Roassal hover text should
disappear when dragging node
http://code.google.com/p/moose-technology/issues/detail?id=824
Taking for example ROMondrianExample >> labeledRectangle...
Hovering over a node shows a popup with the node text,
then moving away from the node makes the popup disappear - which is fine.
Hovering over a node shows a popup with the node text,
then dragging the node away doesn't close the popup - but I think it should.
Additionally, if you drag the node to the popup and leave it there, then
moving the mouse away does not close the popup either.
Moose47 - ConfigurationOfMondrian.485
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 823 by google....(a)ben.coman.com.au: buttons remains after
ROMondiranExample >> chooseLayout
http://code.google.com/p/moose-technology/issues/detail?id=823
From Roassal Easel > Example...
clicking "chooseLayout" then clicking "Example" doesn't cleanup the buttons
from "chooseLayout"
Moose47 - ConfigurationOfRoassal.485