Moose-dev November 2011

moose-dev@list.inf.unibe.ch

25 participants
191 discussions

Issue 543 in moose-technology: inFusion does not export in UTF-8
by moose-technology＠googlecode.com 11 Feb '12

11 Feb '12

Status: New Owner: ---- CC: georgega...(a)gmail.com Labels: Type-Defect Priority-Medium Component-ExternalTools New issue 543 by tudor.gi...(a)gmail.com: inFusion does not export in UTF-8 http://code.google.com/p/moose-technology/issues/detail?id=543 MSE should be in UTF-8.

1 2

Re: Issue 551 in moose-technology: VerveineJ should export parameterized types
by moose-technology＠googlecode.com 11 Feb '12

11 Feb '12

Comment #2 on issue 551 by tudor.gi...(a)gmail.com: VerveineJ should export parameterized types http://code.google.com/p/moose-technology/issues/detail?id=551 Currently, ParameterizableClass is exported, but the instances are duplicated.

1 3

Issue 532 in moose-technology: inFusion should also export PrimitiveTypes
by moose-technology＠googlecode.com 11 Feb '12

11 Feb '12

Status: New Owner: ---- CC: georgega...(a)gmail.com Labels: Type-Defect Priority-Medium Component-ExternalTools New issue 532 by tudor.gi...(a)gmail.com: inFusion should also export PrimitiveTypes http://code.google.com/p/moose-technology/issues/detail?id=532 void, long, int, boolean, char, char[] ... should be PrimitiveTypes, not Classes

1 3

Re: Issue 440 in moose-technology: FamixInvocation>>to should return candidates instead of receiver
by moose-technology＠googlecode.com 11 Feb '12

11 Feb '12

Updates: Status: Fixed Comment #2 on issue 440 by simon.de...(a)gmail.com: FamixInvocation>>to should return candidates instead of receiver http://code.google.com/p/moose-technology/issues/detail?id=440 Fixed as first part of MooseChef integration

1 1

Re: Issue 420 in moose-technology: Shape should be properly initialized to be useful without further parameter
by moose-technology＠googlecode.com 11 Feb '12

11 Feb '12

Comment #3 on issue 420 by tudor.gi...(a)gmail.com: Shape should be properly initialized to be useful without further parameter http://code.google.com/p/moose-technology/issues/detail?id=420 Is this still an issue?

1 3

Re: Issue 322 in moose-technology: Add status bar to MOBrowser and MOEasel
by moose-technology＠googlecode.com 02 Jan '12

02 Jan '12

Updates: Labels: -Milestone-4.2 Comment #9 on issue 322 by tudor.gi...(a)gmail.com: Add status bar to MOBrowser and MOEasel http://code.google.com/p/moose-technology/issues/detail?id=322 (No comment was entered for this change.)

1 4

Issue 499 in moose-technology: Port & transmission in Mondrian
by moose-technology＠googlecode.com 02 Jan '12

02 Jan '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Mondrian New issue 499 by alexandr...(a)gmail.com: Port & transmission in Mondrian http://code.google.com/p/moose-technology/issues/detail?id=499 Hi Alex, -=-=-=-=-= Previous discussion: What we did in Glamour was to attach to each Presentation a kind of default interaction. In your example, I would make #mouseEnter, #mouseClick ... default ports that are populated when the corresponding interactions happen on a graph element. Then of course, these ports will belong to graph elements. Like this transmissions are created between the ports of a graph element. Perhaps there will also be a need to identify graph elements by name so that you can refer to them from outside the context of a script. -=-=-=-=-= Previous discussion: Why not having ports that belong to an interaction instead? Consider the following script: view nodes: (1 to: 1000). Figure selection will imply a transmission between the root and each of these nodes. It could be a single transmission between 'root interaction' and the unique interaction of the nodes? -=-=-=-=-= Doru answer: At least two reasons. First, the ports are not just for transmitting information, but ports also allow you to store arbitrary values that model the graph element, and thus you can model the state of a visualization (including side-effects). Second, using ports you will be able to let the shape populate ports by default without writing any explicit interaction (only write transmission when you want to deal with them). Now, about we can be smart about transmissions and do what we do for shapes: we share the object between multiple graph elements. For this, we will just need a lookup of the origins instead of hardcoding them. Actually in Glamour, we have: GLMTransmission>>originatesAt: aPort and thus, you can have a smart transmission that performs a more complex check by checking if the port is part of any elements from a collection. Like this you will have only one the transmission object. You could write: view nodes: #(1 2 3) labeled: #interestingNodes. view nodes: #(5 6 7) labeled: #otherNodes. view transmitTo: #otherNodes fromAny: #interestingNodes port: #selection. Cheers, Doru

1 2

Issues with the new Mondrian Easel
by Alexandre Bergel 09 Dec '11

09 Dec '11

Hi! I found the new easel often quite problematic. Here is a list of issues I have found: - Time to time, pressing Ctrl-s does not execute the script, especially on Linux boxes. It instead accepts the text pane instead of executing. I cannot really reproduce it (I do not have a linux right now), but students have experienced this several times - When the UI thread crashes, a new easel has to be opened. For example, execute the script: -=-=-=-=-=-=-=-=-= self foo view nodes: (1 to: 20) -=-=-=-=-=-=-=-=-= It will raise a debugger. Remove the "self foo", and press the check or Cmd-s, then I have the same error, even though "self foo" is not in the script. - Examples are crucially missing. These 3 points are quite disturbing for the students. It would be cool to have a sprint on the new easel. I like the fact it is the same UI concept than the rest of the Moose UI. Shall I open issues for each of these points? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 4

Issue 645 in moose-technology: we should keep the current selected tab in the moose panel
by moose-technology＠googlecode.com 06 Dec '11

06 Dec '11

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 645 by cy.delau...(a)gmail.com: we should keep the current selected tab in the moose panel http://code.google.com/p/moose-technology/issues/detail?id=645 In the moose finder, If I click on an entity, I have a new pane that open on the right. In this new pane, if I select any tab, this one should stay selected when I click on other entities

1 3

Mondrian expandable nodes
by Martin Dias 05 Dec '11

05 Dec '11

Hi During Smalltalks conference, we started with Mariano and Doru to do an experiment: to use Mondrian to visualize the graph that is being serialized with Fuel. I want to make two questions about that: 1) Is it fine how I installed Mondrian? Gofer it squeaksource: 'Mondrian'; package: 'ConfigurationOfMondrian'; load. (ConfigurationOfMondrian project latestVersion) load. 2) For large graphs, I would like to show them lazily, maybe drawing some expandable nodes (+). Do you understand what I mean? Is that possible? thanks! Martin

4 21

← Newer
1
...
5
6
7
8
9
10
11
...
20
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2011