Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Alexandre Bergel

Hi! I do not get an example with DCRTFocusable. What does this interaction do? I tried the following and it does not seem to do much. -=-=-=-=-=-= b := RTMondrian new. b shape rectangle width: #numberOfVariables; height: #numberOfMethods. ns := b nodes: RTShape withAllSubclasses. es := b edges connectFrom: #superclass. es @ DCRTFocusable. b layout tree. b -=-=-=-=-=-= Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 9 months

Roassal observing click on any and all elements

by Peter Uhnák

Hi Alex, I'm trying to find a way how to observe all mouse clicks regardless of elements. I can do this easily on my side, because I have control over everything I create, but doing that would prevent certain things like RTResizable from working in pure Roassal... Currently all Trachel mouse events are created in Morphic (TRMorph), however events themselves are fired from shapes' announcers so there is no convergence point. So, would it be possible to basically fire the event twice, once from the shape's announcer and once from probably view or canvas (or some TROverseer class or whatever). As far as performance goes this shouldn't be a problem if you consider that just mouse movement can trigger 10 events every second. What do you think? Is it worth for you to change/implement it? If not I will resolve it on my side. Thanks, Peter

9 years, 9 months

Roassal addedIn event

by Peter Uhnák

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

9 years, 9 months

Roassal plugins

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 9 months

Telescope [was Re: Roassal3 and Bloc]

by Peter Uhnák

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

9 years, 9 months

[Roassal] Changing the height of a bar in RTStackBarPlot does not work

by roberto.minelli＠usi.ch

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

9 years, 9 months

Option to send data from Spotter

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 9 months

Method extension, childnamedEntities, MooseChef...

by Anne Etien

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

9 years, 9 months

Re: Using Spotter for script

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 9 months

Using Spotter for script

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

9 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev