Moose-dev September 2011

moose-dev@list.inf.unibe.ch

30 participants
165 discussions

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

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

Issue 558 in moose-technology: Better visitor for Mondrian
by moose-technology＠googlecode.com 19 Nov '11

19 Nov '11

Status: New Owner: ---- CC: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Mondrian New issue 558 by alexandr...(a)gmail.com: Better visitor for Mondrian http://code.google.com/p/moose-technology/issues/detail?id=558 Shapes are not correctly handed by MOVisitor. We should move all the display:on: methods of the shapes in a visitor. The goal is to make the core of Mondrian free of any canvas reference. By doing so, we will produce exporter for HTML5 and Javascript...

1 1

Issue 594 in moose-technology: Cleaning MOAnnouncer
by moose-technology＠googlecode.com 18 Nov '11

18 Nov '11

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 594 by alexandr...(a)gmail.com: Cleaning MOAnnouncer http://code.google.com/p/moose-technology/issues/detail?id=594 It contains many unused methods: registerForEvent: eventClass forNodes: aBlockOrSymbol updateNode: updateBlock updateLayout: aBoolean registerForEvent: eventClass forNode: aBlockOrSymbol updateShape: updateBlock updateLayout: aBoolean toggleAllProcesses

1 1

Issue 696 in moose-technology: inFusion should export the declaredType
by moose-technology＠googlecode.com 16 Nov '11

16 Nov '11

Status: New Owner: georgega...(a)gmail.com Labels: Type-Defect Priority-Medium Component-ExternalTools New issue 696 by tudor.gi...(a)gmail.com: inFusion should export the declaredType http://code.google.com/p/moose-technology/issues/detail?id=696 Method, Function, and StructuralEntities should have a declaredType

1 1

Re: Issue 416 in moose-technology: method invocation in Java don't fit metamodel
by moose-technology＠googlecode.com 16 Nov '11

16 Nov '11

Updates: Cc: anquetil...(a)gmail.com Comment #4 on issue 416 by tu...(a)tudorgirba.com: method invocation in Java don't fit metamodel http://code.google.com/p/moose-technology/issues/detail?id=416 Should we build AttributeInitializer as a subclass of BehavioralEntity?

1 2

Re: Issue 417 in moose-technology: Writing informations in a Transcript
by moose-technology＠googlecode.com 16 Nov '11

16 Nov '11

Updates: Labels: -Component-Mondrian Comment #7 on issue 417 by alexandr...(a)gmail.com: Writing informations in a Transcript http://code.google.com/p/moose-technology/issues/detail?id=417 Mondrian contains just one "Transcript show:", when doing the benchmark. I consider it acceptable

1 2

Re: Issue 321 in moose-technology: Problems using java code importer with inFusion in windows
by moose-technology＠googlecode.com 16 Nov '11

16 Nov '11

Updates: Labels: -Platform-Squeak Platform-Pharo Comment #1 on issue 321 by tudor.gi...(a)gmail.com: Problems using java code importer with inFusion in windows http://code.google.com/p/moose-technology/issues/detail?id=321 The command should be taken away from the menu until OSProcess works properly.

1 4

Re: Issue 114 in moose-technology: Resizable panes in Finder
by moose-technology＠googlecode.com 16 Nov '11

16 Nov '11

Updates: Labels: -Milestone-4.2 Milestone-4.3 Comment #6 on issue 114 by tudor.gi...(a)gmail.com: Resizable panes in Finder http://code.google.com/p/moose-technology/issues/detail?id=114 The basic structure is in place. There are still a couple of things to do: - include the changes to GeneralScrollPane - solve the small scrolling animation problem

1 4

Re: Issue 334 in moose-technology: While computing duplication SmallDude does not show a progress bar
by moose-technology＠googlecode.com 16 Nov '11

16 Nov '11

Comment #5 on issue 334 by tu...(a)tudorgirba.com: While computing duplication SmallDude does not show a progress bar http://code.google.com/p/moose-technology/issues/detail?id=334 Issue 667 has been merged into this issue.

1 2

← Newer
1
...
4
5
6
7
8
9
10
...
17
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 September 2011