Thank you for all the suggestions. I looked more closely at Roassal and it
seems that it might have everything we would need. Basically the next step
in the project is to create extensible drawing tool for modelling languages
(UML/Petri nets/what have you), so we need to be able to draw any arbitrary
shapes and their compositions (e.g. UML StateMachine composite state might
have plethora of subelements). So If I understand correctly Roassal/Trachel
should be able to provide us with everything at the visual layer or it is
possible to (easily) extend it and add custom shapes.

Peter


On Sun, Jul 6, 2014 at 1:27 PM, Nicolai Hess <nicolaih...@web.de> wrote:

> 2014-07-06 9:54 GMT+02:00 stepharo <steph...@free.fr>:
>
> Hi peter
>>
>> I hope that igor will see your mail now I will try to reply and this may
>> be a bit wrong :)
>>
>>
>>  Hello,
>>>
>>> I'm currently working on drawing engine (à la Squeak Connectors) as a
>>> part of school project and have a couple of questions about Morphs and
>>> Athens and would be grateful if someone could enlighten me.
>>>
>>> What is the difference between "Morph>>#drawOn:" and
>>> "Morph>>#drawOnAthensCanvas:" if I draw  on AthensCairoSurface? Should I
>>> always use the latter or will there be switch to the former once everything
>>> is rendered using Athens?
>>>
>>
> AthensWrapMorph fullDrawOn method will call its submorphs drawOn: method
> with an AthensCanvas.
> Now, if you have an AthensCanvas (from the  AthensWrapMorph) and your own
> Morph does not implement drawOnAthensCanvas, then
> Morph>>#drawOnAthensCanvas is called which just
> draws an rectangle from your Morphs bound. For example, put a PolygonMorph
> on an AthensWrapMorph. It is drawn as a rectangle, because PolygonMorph
> does not know (yet) how
> to draw itself with athens.
>
>  If you have new a Morph that is just container of other Morphs than you
> don't need to change anything. Just make sure your toplevel Morph
> is wrapped by an AthensWrapMorph. But If you have a Morph, that subclasses
> another Morph that overrides drawOnAthensCanvas, you'll have to reimplent
> this as well.
> For example, MenuItemMorph subclasses StringMorph and StringMorph
> implements its own drawOnAthensCanvas. If you put a MenuMorph in a
> AthensWrapMorph it will be drawn
> like a plain StringMorph not like a MenuItemMorph (without icons and
> arrows for submenus etc).
>
>
>>  One of the idea is that you have a wrappingMorph that convert the
>> Morphic to Athens drawing. This way
>> you can use athens and still be in a non athens world, then we will
>> switch to athens you will just have to unwrap your (athensihed morph).
>
>
>> Now about the granularity question it depends, what I would do is to have
>> one wrapper and be in a athens world.
>> Did you check the trachel layer in Roassal?
>>
>
> I may be wrong, but I think we have to be carefull that not everyone
> invents its own "draw on athens layer".
>
> I would suggest:
> - build it on top of roassal / trachel, i.e. draw always with athens.
> - build it as Morphs and implement drawOnAthensCanvs if needed.
>
> Nicolai
>
>
>
>>
>> What would be good is that
>>     - you define drawOnAthensCanvas: for all the shapes you need and we
>> integrate them into Pharo
>>     - like that slowly we will get ready to switch to Athens
>>
>>
>>  Should AthensMorphWrap be around every morphic element or just the top
>>> level? i.e.
>>> CanvasMorph (owner of the surface) will have a single submorph
>>> AthensMorphWrap which will then hold all the morphs (EllipsisMorph,
>>> RectangleMorph, ...) which are being drawn on the canvas.
>>>
>> I think so.
>> This is what Roassal is doing.
>> Please keep us aware of your progress and do not hesitate to ask
>> questions and we are REALLY interested in your project
>
> So if you have athens draw on method please send them to us.
>>
>
>> Stef
>>
>>
>>> Thanks,
>>> Peter
>>>
>>
>>
>>
>

Reply via email to