Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Simon Denier

Hi list I am looking for any media material (picture, screenshots of tools, slideshow, videos, podcasts) related to Moose. Some could be put on the website for the community, and I think they should be put in a file repository to be shared under a CC licence. Right now I am working on a poster for Moose and that's why I need such materials. -- Simon

16 years, 1 month

[SqMondrian] MOFigureSelection

by Alexandre Bergel

Hi All, Doru emitted a request on Mondrian. I added the class MOFigureSelection to capture when a node is selected. Example in: MOViewRendererTest>>testFigureSelection | view node1 announcer | view := MOViewRenderer new. view setUsefulHandlersForNodes. announcer := view interaction. view nodes: (1 to: 20). node1 := view nodeForDomainValue: 1. self deny: (node1 isSelected). announcer announce: (MOFigureSelection event: nil on: node1). self assert: (node1 isSelected). Note that the message setUsefulHandlersForNodes should be sent to the view. It is automatically sent within an easel. (maybe this is a point we could discuss). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

16 years, 1 month

Re: [Pharo-project] FAMIXAssociation

by Tudor Girba

Hi Alex, I guess this was meant for moose-dev :). The previous/next point to other associations, and they can be used to indicate the order of associations. Cheers, Doru On 10 Mar 2009, at 22:59, Alexandre Bergel wrote: > Dear list, > > Why an association has a previous and a next ? > What are these variables for? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

16 years, 1 month

Fame.AbstractCodeGenerator>>previewChanges does not compile

by Mircea Lungu

Hey guys, I use Fame (ver 0.372 form the bern store) and I want to generate code for a metamodel. The code int the AbstractCodeGenerator>>previewChanges does not compile. As the image shows, it does not find the Sensor and ORChangeBrowser classes. Is there another prerequisite that I should load. Thanks, Mircea.

16 years, 1 month

VW UI: Change label width in a UI.SequenceViewSpec

by Simon Denier

Hi list First I'm not proficient at all with how the visualworks UI works and how to change the design within a widget. I'm just *trying* to get the width of each item in the list below larger, so that each displays the full text. Poking around, it is a UI.SequenceViewSpec widget. I tried to change the #style attribute, but it does not change the width. -- Simon

16 years, 1 month

Re: Mondrian ViewRenderer

by Alexandre Bergel

Hi Jannik, [Jannik is porting his work on DSM from VW to Pharo] Currently, a view renderer does not understand the message newShape. I am still unconvinced that having this newShape is a good thing. Maybe Doru can tell us a bit more about that. It is not obvious why a ShapeRenderer is necessary. It contains a list of shapes that I cannot clearly figure out what this is useful for. Cheers, Alexandre On 5 Mar 2009, at 18:28, Laval Jannik wrote: > Est-il possible d'avoir la méthode newShape dans MOViewRenderer ? > > J'ai porté DSM sur Pharo et il a besoin de cette méthode. > Je peux le faire si le portge est simple :) > > --- > Jannik Laval > PhD Student - Software Quality - INRIA > Certified Project Management Associate (IPMA) > http://www.jannik-laval.eu > http://rmod.lille.inria.fr > --- > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

16 years, 1 month

[SqMondrian] node traversal and UndefinedObject>>display: anElement on: aCanvas

by Simon Denier

Hi there I browse the code of SqMondrian to understand how it works (with the previous help of Alex) and after a while, I wondered how the traversal of nodes and edges was really done. It seems like traversing the graph and drawing shapes are deeply intertwined. It took me a bit of time to figure out, but it seems that the following method defined for the nil object is very important :) UndefinedObject>>display: anElement on: aCanvas anElement display: anElement on: aCanvas The call sequence look like: @rootnode#displayOn: -> nil#display: rootnode on: aCanvas -> (...) rootnode children#displayOn: aCanvas -> ... -> shape#display: aNode on: aCanvas -> nil display: aNode on: aCanvas -> aNode children#displayOn: aCanvas -> ..... Or, from Root to nil to root children to child shape to nil to child to children of child to shape to nil to ....etc. It's quite weird how it always goes through nil to launch and continue the traversal :) Not discussing the previous design which had its own reason, but now that we have separate composite shape, I think we can also separate the nodes traversal logic from the shape drawing logic for clarity. -- Simon

16 years, 1 month

Re: [Mondrian] graphelements traversal

by Alexandre Bergel

[Sorry for having part of this email in French, we are talking about optimizing and graph traversal in SqMondrian] > J'ai compris comment fonctionnait la traversée et le dessin des > éléments/shapes dans Mondrian. En fait, les deux sont mixés > > A chaque fois que tu fais le display sur une shape, tu as : > > Shape>>display: anElement on: aCanvas > (...) > next display: anElement on: aCanvas > > Sauf que next est toujours à nil dans la version actuelle de > Mondrian ! Legacy code. Yes, I fixed this. > et là c'est bon, on repart sur > GraphElement>>display: anElement on: aCanvas > aCanvas translateBy: self bounds origin during: [ :canvas | > self nodes do: [ :each | each displayOn: canvas ]. > self edges do: [ :each | each displayOn: canvas ] > ] > > NB: anElement est inutile dans les Element You're right. We should fix this. > La cerise sur le gateau : quand on lance le dessin sur le root node, > on a > > Element>>shape > display: self > on: aCanvas > > mais shape est nil pour le Root node, donc on passe par > UndefinedObject et là c'est bon :) > > > > OK il devrait y avoir moyen de clarifier ça pour faire la traversée > directement niveau node dans displayOn: et pas via les Shape. Yes, the shape knows nothing about the graph structure. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

16 years, 1 month

Re: Mondriand edge and bounds

by Alexandre Bergel

Hi Simon, Edges are quite slow to draw. I introduced a new method that exemplifies such a situation. Just execute: MessageTally spyOn: MOBenchmarks new edges This method render 1000 times 30*30 edges. You will see that 96% is spent in MOStraightLineShape>>display:on: Within this 96%: - about 37% in MOEdge(MOFigure)>>display:on: (26% in BalloonCanvas(FormCanvas)>>translateBy:during:) - about 33% in BalloonCanvas>>drawPath:borderWidth:borderColor: - about 10% in MONode(MOFigure)>>bounds There are rooms for improvement here. An obvious one is to replace IdentityDictionary by RBIdentityDictionary. I just did this in the last version of Mondrian, and I gained 26% of gain. Apparently, the bounds is computed twice. This could probably be optimized as well. >> Je pense avoir trouvé une des raisons pour laquelle le dessin des >> edge est si lent. Dans le code actual des displayOn:.... la >> position des edge est recalculée à chaque fois. Le bounds des >> element source/target est utilisé dans le calcul, mais le bounds du >> edge lui-même n'est jamais initialisé et pas exploitable. > > Exemple pour StraightLineShape > display: anElement on: aCanvas > |bounds| > bounds := anElement boundsOf: self. > aCanvas > drawPath: (Array > with: (bounds origin) > with: (bounds corner)) > borderWidth: (self widthFor: anElement) > borderColor: (self colorFor: anElement). > next display: anElement on: aCanvas > > > Ca marche sauf si les node sont draggable, dans ce cas les bounds > des edges ne sont pas mis a jour par le drag. C'est pas très clair > comment propager un événement Node sur les Edge connectés pour > l'instant A MOGraphElement has a variable edges. I do not think this variable is used at all. Maybe you could rename this variable edges -> cacheEdges and use this variables to store outgoing edges. I would like to enforce the fact that a variable is a cache. This is an important information. It is often hard to distinguish variables that are conceptually relevant, and the ones that are use to caches values. Thanks for your effort. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

16 years, 1 month

Moose Mailing List Activity

by Francois Stephany

Hi all, I'm developing a tool to mine mailing lists in Moose (called Maispion) In this context, i'm playing with code_swarm[1]. It is a visualization tool that shows the CVS commits history of a project. Here's a *preliminary* video of the Moose mailing list i get from it (tweaked to display emails instead of commits): http://www.tulipemoutarde.be/documents/mooseDevMovie.avi I have some ideas to improve it but would like to hear from you if you have any suggestions to make this visualization cooler (or, maybe, even useful :) Cheers, Francois [1] http://vis.cs.ucdavis.edu/~ogawa/codeswarm/

16 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev