18 Nov
2013
18 Nov
'13
9:44 p.m.
Hi Stef,
Your email made me think a lot.
But in roassal you do not have the concept of a
polylines?
Actually no, but it is likely that we should. A general way to defines polygons is the way
to go.
I do not get why you want to pollute Roassal with SVG
names.
If you introduce the notion of Path why don;t you do it independent of SVG
because SVG is one way to represent path.
After having played with Athens, I understand better what you actually mean.
Indeed, the end user should work with a notion of polygon in general, and not with SVG.
Because I think that as a user I do not want to if my
code works on svg or another external format.
You are very very right. We indeed do not want to introduce all these classes.
Your email made me think about something: rewriting Roassal from scratch, but putting the
core notions brought by Athens at the center of Roassal. I spend some time on getting the
camera working in Roassal, but Athens was not ready yet. More Roassal will use Athens, and
more we are taking advantages of the graphic card.
Also, do we have to wait for the text editor to include Athens in Pharo? The text editor
is essentially to bootstrap and remove Morphic right? But until then, Athens could be part
of Pharo. I am now using the Moose image, which is nicely packaged with proper fonts and
Athens. Since there are many users of Roassal on Morphic, it is hard for me to move to
100% Athens.
Thanks again for your email
Alexandre
It follows the same pattern no?
Yes but this is different because ROBox is a roassal box not an svg or another format.
If tomorrow you get a pdf reader and access a library of pdf library. Do you want your
reader to
have ROPDFBox?
in SVG you also have
• Rectangle <rect>
• Circle <circle>
• Ellipse <ellipse>
• Line <line>
• Polyline <polyline>
• Polygon <polygon>
• Path <path>
So I imagine (and hope) that you will not introduce ROSVGRectangle ROSVGLine
ROSVGCircle?
So why introducing ROSVGPath
Stef
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre
On Nov 17, 2013, at 8:45 AM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I see that you have a loooot of fun.
Now I have the impression that in the future version you should not expose ROSVGPath and
others
because there are at the importer level not Roassal. So why do you need to wrap them.
If there is something missing in SVGPath what is it?
Stef
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I had fun understanding how countries may be described using SVG.
Here is a first shoot:
<Screen Shot 2013-11-16 at 5.36.21 PM.png>
Moving the mouse above a country name highlight the country. You can now rehearse your
geography.
The complete source code of this example is:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| view element nameComponent label |
view := ROView new.
ROSVGPath countries do: [ :k |
element := (ROSVGPath path: (ROSVGPath perform: k)) elementOn: k.
view add: element.
].
nameComponent := ROElement new.
ROSVGPath countries do: [ :k |
label := ROLabel elementOn: k asString.
label @ ROLightlyHighlightable.
label on: ROMouseEnter do: [ :event | ROBlink highlight: (view elementFromModel: event
model asSymbol) ].
label on: ROMouseLeave do: [ :event | ROBlink unhighlight: (view elementFromModel: event
model asSymbol) ].
nameComponent add: label.
].
ROGridLayout new
gapSize: -3;
lineItemsCount: 15;
on: nameComponent elements.
view add: nameComponent.
nameComponent translateTo: 0 @ 400.
view openInWindowSized: 1000 @ 700
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.