Moose-dev October 2012

moose-dev@list.inf.unibe.ch

25 participants
139 discussions

Roassal ROShorterDistanceAttachPoint: refactoring and possible enhancement
by Dennis Schenk 09 Oct '12

09 Oct '12

Hi all, I saw two instances of code duplication in ROShorterDistanceAttachPoint so I refactored the class, changed some method names to make their purpose cleaner and added some comments. @Alexandre: If you like the changes, could you integrate them into Roassal? The filed out class can be found here: http://cl.ly/code/392s3y1V2A0N In a next step I added an offset parameter which can be used to offset the attach point positively or negatively on one of the four possible attach 'sides'. The purpose of the offset can be seen in the following screenshot: http://cl.ly/image/0d343Z1L0b00 It allows for example to have multiple edges from and to the same element (with different offsets). I'm note sure whether you would want the offset-possibility in ROShorterDistanceAttachPoint or if I should create a subclass for it. If you'd like to integrate it directly, the filed out class with the offset parameter can be found here: http://cl.ly/code/1T3c310J2r06 If not I will create a subclass. Cheers, Dennis

2 1

Jenkins build became unstable: moose-latest-dev #1156
by admin＠moosetechnology.org 08 Oct '12

08 Oct '12

See <http://hudson.moosetechnology.org/job/moose-latest-dev/1156/>

1 2

Glamourous Inspector - multiple panes
by Ben Coman 08 Oct '12

08 Oct '12

Using a 24" wide screen, it would be useful to be able to configure the Glamourous Inspector [1] to have more than two panes showing at a time. Is that possible? cheers -ben

2 3

Re: [Pharo-project] Roassal Survey
by Ben Coman 08 Oct '12

08 Oct '12

1 0

Issue 850 in moose-technology: GT should offer a setting for the number of panes in the inspector
by moose-technology＠googlecode.com 08 Oct '12

08 Oct '12

Status: New Owner: tu...(a)tudorgirba.com Labels: Type-Defect Priority-Medium Component-GlamorousToolkit Milestone-4.7 New issue 850 by tu...(a)tudorgirba.com: GT should offer a setting for the number of panes in the inspector http://code.google.com/p/moose-technology/issues/detail?id=850 We should be able to set the amount of panes visible at one time in the inspector. This is useful when having a large monitor.

1 1

Re: [Pharo-project] Roassal Survey
by Tudor Girba 08 Oct '12

08 Oct '12

Hi, On Sun, Oct 7, 2012 at 10:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> if you check the sender of #mostSpecificParentCommonWith: then you will see that only the Mondrian builder makes use of it. Currently, and outside the Mondrian DSL, you can insert the edge where you actually want, independently of its extremities. >> >> Is there a reason for this "freedom" in Roassal? > > Simplicity of the code. Currently there is absolutely no optimization or even caches in Roassal. > I have the feeling that this point will be crucial when we will have to address some scalable situations. But, this is not an optimization. Storing edges in reasonable places is about the meaningfulness of the model. Perhaps it makes sense to have it like it is now in Roassal, but I think there should be an explicit reason for it. That is because a graph has essentially two concepts, and if one of them is randomly placed, the model is only 50% sound :). Regarding caches, the original Mondrian had no cache either precisely because we wanted to keep it open. Caches were introduced only very late in the Pharo version because you wanted to make it faster :). It is clear that we learnt that hard and extensive caches impose limitations and I never argued for them. >>> I am wondering whether this is what we really want. Shouldn't the element/node be aware of its attachpoint, instead of its edges? >> >> I think you should have both. There should be a lookup, where the node >> should have the priority over the edge. > > > Probably yes. We tried something like this in Mondrian, but the model was not quite clean. There, even the layout could set the attachment points. It would be cool to rethink this part. Cheers, Doru > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -- www.tudorgirba.com "Every thing has its own flow"

1 0

ROMenuActivable on raw graphic elements
by Ben Coman 07 Oct '12

07 Oct '12

I have split this post into two parts since I think any follow up will form two distinct threads. As I am developing using Roassal, I find it useful to Explore the graphic elements from a context menu. To demonstrate I have adapted ROExample>>linesOn: "-------------" "-------------" menu := (ROMenuActivable new) item: 'Explore graphic element' action: [ :model | (rawView elementFromModel: model) explore ]. node1 := ROLabel elementOn: 'node1'. node2 := ROLabel elementOn: 'node2'. node1 @ RODraggable @ menu. node2 @ RODraggable @ menu. "uncomment next three lines for Part Two edge := ROEdge lineFrom: node1 to: node2. edge + (ROLine red). rawView add: edge. " rawView add: node1; add: node2. ROHorizontalLineLayout on: (Array with: node1 with: node2). "-------------" "-------------" Is there (or can there be added) a way to access the graphic element more directly? Something like one of the following two lines... item: 'Explore graphic element' action: [ :model :element | element explore ]. item: 'Explore graphic element' rawAction: [ :element | element explore ].

2 5

Interactive Roassal (.5)
by Ben Coman 07 Oct '12

07 Oct '12

I have updated my try at a Roassal-Interactive demo (see attached) to the latest ConfigurationOfRoassal (AlexandreBergel.625). This is specifically to make use of the ROMenuActivable change to use graphic elements rather than nodes. I haven't got a home for this yet. Are there any parts of this that might be included under the main Roassal repository (probably under a separate Configuration due to the dependency on Glamour), or should a start a separate repository? Also are there any parts (especially the extensions to the Roassal-Glamour interface) that might get into mainline - or do you see other ways of achieving this.) cheers -ben

1 0

Re: Status of PetitDelphi, a first visualization
by Stephan Eggermont 06 Oct '12

06 Oct '12

Alexandre wrote: > Looks good! > Using Roassal will give you some zooming in/out and a find button. > Quite useful :-) Yes, Roassal is definitely on the radar. The demo project is rather large, and zooming will be needed as soon as we add more information. Stephan

2 1

Metrics about Moose itself
by Mariano Martinez Peck 06 Oct '12

06 Oct '12

Hi guys. Let's say I need to know how "large" Moose is. I want an approx. number of classes, package, and total LOC. I can take the default Moose distribution (one-click). Of course I only want to take into account only Moose packages (and its dependencies), but not Pharo itself. I could do it...but it may take some time.. maybe someone already did it. anyone? Thanks, -- Mariano http://marianopeck.wordpress.com

3 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev October 2012