Hi Alex,
I've mentioned this very long time ago, but it wasn't on my radar so I get
back to it just now.
Basically I want to have either:
a) option to execute behavior when element is added to view --- this is
basically direct counterpart to TRRemovedCallback.
So I could do things like...
element addCallback: (TRAddedCallback: [ :shape | "add dependent elements
or whatever" ]).
or
b) have RTInteractions be lazily initialized --- only after the element has
been added to the view.
(or both)
The idea is to have more clearly resolvable interactions like RTLabelled,
which currently requires for the element to be already in the view.
I'm not sure if the second option will be entirely feasible, because many
of the interactions are stateless and require immediate evaluation... but
that could be resolved with some flags or different subclassing or
something...
Is it possible for you? Is this something you want in Roassal?
Thanks,
Peter
Hi!
I am experimenting something. There are several Roassal contributions around, and I try to make them easily accessible. I have designed a very simple plugin system, accessible within the world menu:
Does this make sense?
Maybe we could have DynaCase accessible here
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hmm...
right now I have one burning question:
Why build a completely new layer of indirection with different API instead
of improving and extending Roassal (=Telescope alongside Roassal instead of
on top of it)? It seems like a lot of effort went into creating it while it
would have had bigger and better impact in Roassal...
So, how do you tell builder that you want to color or add interaction to a
>> "group" of nodes and not all the nodes in the visu? Groups are first-class
>> entities in Telescope. Composites are first class entities with
>> customizable interactions.
>>
>> Roassal has RTGroup, which is obviously less powerful, but often enough.
Plus the
"if node matches this add/change/do this" that is also implemented by
Telescope.
> Moreover, the model takes care of updating only the concerned nodes and
>> not all of the visualization.
>>
>> Roassal updates only what should be updated, not the whole visualization.
(And if some particular builder does rerender everything, that's the
builder's problem.) After all this is transitive --- if Telescope can do
partial changes and is on top of Roassal, so can Roassal do it...
> The paper is not the best way to see what Telescope is able to.
>>>
>>> Look at the demos and the presentation Anne did at Esug:
>>> http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-e…
>>>
>>> I saw the presentation at ESUG but I wanted more insight (or
documentation)...
Anyway, I'll continue my exploration... but the idea that I might need
interaction between Telescope and Roassal elements and concepts doesn't
make me happy...
Peter
Hi guys,
Just spotted a bug in RTStackBarPlot.
If you set the height of a bar with the message #barWidth:height: the width is set but the height remains 20 pixels, as defined in #defaultBarHeight.
To reproduce, go to RTStackBarPlot>>#example03 and change the height value parameter in the #barWidth:height: message. Bar always remain 20 pixels.
P.s. I also take this opportunity to say that once you get proficient in Roassal it is really a pleasure to use it!
Cheers,
Roberto
Hi!
I am happy to send data to you guys. Just a small request: can you put the checkbox in the little pink window? Each time I download an image, I have to open the preference browser, which is… a bit painful.
Picky me :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
I am working on a new generic version of MooseChef. The idea is that from an element, we can reach its children by looking at the entities whose opposite of the « belongsTo » property is this element. The idea is not to take into account the specificities of the FAMIX context as it is done currently, but to use an API that is not aware of the FAMIX concept on which it is applied and thus that is the same for any FAMIX concept already existing or not yet.
Currently, we got different issues:
1. in Smalltalk, classes are in the childnamedEntities collection of a FAMIXPackage whereas they are in the types of a FAMIXNamespace in Java. The problem is that FAMIXClass has not its own belongsTo method, but inherits it from FAMIXType. So the opposite of the belongsTo method for a FAMIXClass is types and not childnamedEntities.
2. in Smalltalk, extension methods are also in the childnamedEntities collection of a FAMIXPackage. However, if you invoke the belongsTo method from an extension method, you get the class and not the package. Moreover, in the current version of MooseChef, associations from and to an extended method are taken into account both when querying the class and the package. In a kind of way, an extended method belongs to both the class and the package. However, it is not possible at the model level to say that an element belongs to two elements.
We can fix the first issue by modifying the SmalltalkImporter and the FAMIX model in order that classes are collected in the types collection as in the case of Java. Consequences on the new version of MooseChef are the following: we can reach the classes from the package what is not possible currently and the association from and to the extension methods are considered only when querying the class belonging these extension methods, but not the package.
What do you think about this change?
Anne
Excellent!
Alexandre
> On Jul 21, 2015, at 5:33 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote:
>
> Hi!
>
>> On Jul 21, 2015, at 12:22, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
>>
>> Hi!
>>
>> I have a quick question. In spotter, if I type “Roassal #c” then I get all the classes that match Roassal. If I enter “Roassal #p” then I get all the packages.
>> How can I get all the scripts contained in the stash folder?
>
> The category is called “Playground named pages”. You can write #p, #pl, #pla, or #play. There two categories, the second one is called “Playground cached pages”. So you obtain both categories, not only one.
>
>>
>> What are the associations between # shortcuts and displayed categories?
>
> It is #<prefix of a displayed category>, e.g., for a class category you can write #c, #cl, #cla, #clas, #class. You cannot use space.
>
>>
>> I am asking this since I now use Juraj’s setting to share stash playground scripts among my images. This is fantastic…
>
> Indeed, it is cool to share the named and cached scripts between images.
>
> Cheers,
> Juraj
>
>>
>> Cheers,
>> Alexandre
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I have a quick question. In spotter, if I type “Roassal #c” then I get all the classes that match Roassal. If I enter “Roassal #p” then I get all the packages.
How can I get all the scripts contained in the stash folder?
What are the associations between # shortcuts and displayed categories?
I am asking this since I now use Juraj’s setting to share stash playground scripts among my images. This is fantastic…
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
How can I embed a Roassal visualization in Spec? There is the package Roassal2Spec, but since it does not contains any documentation or example, hard to use it :-)
Johan, an hello world example please :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I forgot to ask at ESUG... but what are the plans for moving towards
Roassal3 and Bloc?
Because currently I am very hesitant in engaging with Telescope which may
or may not solve some of my problems... but the code is really, really hard
to read for me.
So from this perspective it might be more fruitful for me to spend energy
on Bloc, provided there will be some more gradual movement from 2 to 3.
Thanks,
Peter