Moose-dev January 2011

moose-dev@list.inf.unibe.ch

23 participants
129 discussions

Re: Issue 191 in moose-technology: Do not execute unnecessary transmissions
by moose-technology＠googlecode.com 20 Mar '12

20 Mar '12

Updates: Labels: -Milestone-4.2 Comment #5 on issue 191 by tudor.gi...(a)gmail.com: Do not execute unnecessary transmissions http://code.google.com/p/moose-technology/issues/detail?id=191 (No comment was entered for this change.)

1 1

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 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

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

Verveine-PHP
by Cyrille Delaunay 13 Nov '11

13 Nov '11

Hello, With nicolas we started to have a look at the eclipse-php-parser (provide with PDT), to export a famix-mse file from a PHP project. We already started to build an eclipse plugin that does some work: => We create an AST for each php file of the project => Then we have a visitor on this ast, and we are therfore able to make a specific action for each kind of node visited => For now, we just export some FAMIXNamespace, FAMIXClass, FAMIXMethods. So what's left is to implement each visit-method to extract informations for each node visited. For that we will have to know a bit more PHP :) Maybe the metamodel will have to be extended to take into account some PHP-specific elements, I don't know. If you want to have a look, sources are available via svn at: https://scm.gforge.inria.fr/svn/lse/Projects/Verveine Vervaine provide the extractor (not yet finished) for Java ans this one for PHP. Both are using a common mechanism to generate famix entities and extract them to mse. I will be on holidays until august and will probably no longer work on it until august. So if you want to have a look (and have the courage to install eclipse to read java code:)), have some suggestions, want to implement something, feel free to participate :)

7 15

Re: Issue 106 in moose-technology: Disable the default Smalltalk shortcuts from the Text Morphic widget in Glamour
by moose-technology＠googlecode.com 05 Sep '11

05 Sep '11

Updates: Labels: -Milestone-4.2 Milestone-4.4 Comment #5 on issue 106 by tudor.gi...(a)gmail.com: Disable the default Smalltalk shortcuts from the Text Morphic widget in Glamour http://code.google.com/p/moose-technology/issues/detail?id=106 (No comment was entered for this change.)

1 3

Re: Issue 464 in moose-technology: Actions that open new browsers should go through Renderer
by moose-technology＠googlecode.com 11 Aug '11

11 Aug '11

Updates: Labels: -Milestone-4.2 Comment #1 on issue 464 by tudor.gi...(a)gmail.com: Actions that open new browsers should go through Renderer http://code.google.com/p/moose-technology/issues/detail?id=464 (No comment was entered for this change.)

1 2

Re: Issue 273 in moose-technology: The Morphic Glamour should update the selectedText in a TextPresentation
by moose-technology＠googlecode.com 14 Jul '11

14 Jul '11

Updates: Labels: -Milestone-4.2 Comment #2 on issue 273 by tudor.gi...(a)gmail.com: The Morphic Glamour should update the selectedText in a TextPresentation http://code.google.com/p/moose-technology/issues/detail?id=273 (No comment was entered for this change.)

1 2

Issue 492 in moose-technology: Glamour browsers do not release all subscriptions to announcer objects
by moose-technology＠googlecode.com 14 Jul '11

14 Jul '11

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-High Component-Glamour Milestone-4.3 New issue 492 by tudor.gi...(a)gmail.com: Glamour browsers do not release all subscriptions to announcer objects http://code.google.com/p/moose-technology/issues/detail?id=492 I noticed that in some complex updating between panels, using an external announcer, some of the update subscriptions were not removed when the browser is closed. I debugged a little and I founded that this implementation: GLMUpdateAction>>unregisterFromAllAnnouncements announcerObjects ifNotNil: [ announcerObjects do: [:each | each unsubscribe: self ] ] is bugged, because if announcerObjects are not previously computed (and in some cases that's what happens), the subscription is not removed. This implementation (just using the accessor instead the direct object), solves the problem (but I don't know is it's a right fix, and it should be a fix in other place) GLMUpdateAction>>unregisterFromAllAnnouncements self announcerObjects ifNotNil: [ :objects | objects do: [:each | each unsubscribe: self ] ] Cheers, Esteban

3 27

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev January 2011