Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

planning moose 4.7 and moving to Pharo 2.0
by Tudor Girba 26 Oct '12

26 Oct '12

Hi, We have to think about releasing Moose 4.7 and moving to Pharo 2.0. There are several reasons why the move to 2.0 would make sense: 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible. 2. The environment moved to RPackage entirely. 3. Pharo needs users. Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points: http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4… The most pressing ones are: Issue 799: Editing code in Glamour must be faster Issue 851: Create a stable version for Moose and all its subparts Issue 853: ConfigurationOfMoose should be split to reflect core vs suite Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker? My idea is to target a release this year. Input is more than welcome :) Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

4 13

borderWith: broken in Roassal?
by Usman Bhatti 24 Oct '12

24 Oct '12

classesToDraw := Collection withAllSubclasses. view := ROMondrianViewBuilder new. view interaction popupText: [:entity | entity name ]. view shape rectangle borderWidth: 1; borderColor: Color blue. view nodes: classesToDraw. view gridLayout. view open Result: Error (Red rectangle) ========================================= classesToDraw := Collection withAllSubclasses. view := ROMondrianViewBuilder new. view interaction popupText: [:entity | entity name ]. view shape rectangle "borderWidth: 1; " borderColor: Color blue. view nodes: classesToDraw. view gridLayout. view open works fine. Can you please check?

2 2

more rubberbanding & interactions on ROView
by Ben Coman 22 Oct '12

22 Oct '12

With the recent integration of RORubberBand, I have then gone to use it in my application. What arises is that while the implementation works well within a single script in ROExample, it is not so well when the creation of elements is more spread out in different parts of the code, since these different parts do not have access to the same instance of RORubberBand. So some further thoughts on rubberbanding for discussion... 1. Since the rubberband operation is between elements, perhaps this should not be stored inside individual ROElements but more globally in ROView. That is, perhaps ROView would have its own interactions. 2. Currently to avoid the MNUs due to the target filter condition processing edges and elements with nil or unsuitable model, in (RORubebrBand>>initializeElement:) I used (candidateTarget getInteraction: self ifPresent:) where it is the 'self' that ensures that source/target elements being compared are applicable to a particular RORubberband. It is that 'self' that is hard to distribute to elements that are created from different parts of the code. Perhaps this mechanism could be replaced by tagging RORubberBand defined in different elements with a common symbol eg #rubberband1 Or tag the elements associated with a particular rubberbanding are just tagged the same as the RORubberBand instance stored in the ROView. 3. Perhaps not bother with trying to ensure no exceptions occur in the execution of the target filter condition, and just mask them out. Rather than interrupting the program with a MNU, targets elements are simply excluded if the filter. What are your thoughts? cheers -ben

2 6

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

21 Oct '12

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

1 2

Roassal Easel working?
by Nicolas Anquetil 18 Oct '12

18 Oct '12

Does Roassal Easel work? I antered the following script: ---- view shape rectangle size: 10 ; height: [:m | m queryAllIncomingInvocations size]. view nodes: methodGroup. view flowLayout. ---- But it does not display anything. Nor does it give any error message The same script works fine otherwise nicolas

2 2

Issue 854 in moose-technology: Roassal Mondrian builder is not handling label based on model
by moose-technology＠googlecode.com 18 Oct '12

18 Oct '12

Status: New Owner: tu...(a)tudorgirba.com Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7 New issue 854 by tudor.gi...(a)gmail.com: Roassal Mondrian builder is not handling label based on model http://code.google.com/p/moose-technology/issues/detail?id=854 ROMondrianBuilder>>label returns the shape, rather than the builder. This implies that setting properties for a label will always talk to the element, instead of the model.

1 2

Issue 855 in moose-technology: Roassal Mondrian builder is not handling color based on the model
by moose-technology＠googlecode.com 18 Oct '12

18 Oct '12

Status: New Owner: tu...(a)tudorgirba.com Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7 New issue 855 by tudor.gi...(a)gmail.com: Roassal Mondrian builder is not handling color based on the model http://code.google.com/p/moose-technology/issues/detail?id=855 Setting the color is directly passed as is to the Shape. The block should be transformed to work with the model instead.

1 2

Mondrian vs Roassal: a conceptual comparison
by Tudor Girba 17 Oct '12

17 Oct '12

Hi, There were several posts that intrigued me lately related to the difference between Mondrian and Roassal, and I did not know exactly why. Now, I think the reason stems from the conceptual difference between the two. So, here I go :) - Roassal is a basic engine that provides a DOM-like graph object model. Its main goal is to enable one to build and manipulate visual objects. - Mondrian is a high level transformation engine. Its main goal is to enable one to transform an arbitrary subject model into a graph visualization. Of course, Mondrian had a basic engine, too, inside, but it was not as flexible as Roassal (especially in the animation part). However, the main point of Mondrian was really to support the transformation. It is for this reason that all blocks in the Mondrian API take the subject model as an input. The target is the developer that knows his model and almost nothing about Mondrian (except for the simple transformation predicates). This was a conscious decision, not a mistake. It is clear that you miss flexibility (e.g., you cannot manipulate the node within an action block), but you gain simplicity for basic actions. Another choice in Mondrian was to focus on the graph model. It is again clear that this decision excluded some classes of visualizations, and as a result several visualizations misused the high-level transformation engine for low level object placing. An example of this is the DSM. It is precisely in this area (and of course others that were not charted yet) that Roassal can play a very important role. I think both points of view are important, and it would be cool to look for solutions that marry both (1) the transformation engine level that speaks mostly the "language" of the original objects, and (2) the graphical engine that offers basic blocks for visual manipulation. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

3 16

JSON API use in Pharo
by Dennis Schenk 16 Oct '12

16 Oct '12

Hi all, I'd like to read and parse JSON from a URL or alternatively from files. Could anyone point me in the right direction to achieve this? Is a JSON Parser available in Pharo or is there a project which provides this functionality? Cheers, Dennis

2 3

How to export multiple Pharo packages to VW
by Stephan Eggermont 15 Oct '12

15 Oct '12

The VW5PackageExporter allows the exporting of a package to the VW xml based fileout format. I've adapted the code to be less Seaside-specific, and am now able to export one package (Parasol-Core). If I try to export another package (Parasol-Tests), which depends on the earlier one, it fails to load. It can't resolve the dependency to a superclass defined in Parasol-Core. I've seen that Roassal puts all Pharo packages into one VW package. That would work, but is not very nice. A package in VW doesn't seem to register its dependencies in a fileout. Would creating a parcel help, or should I try something on basis of RPackage? Stephan

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev