Moose-dev March 2012

moose-dev@list.inf.unibe.ch

32 participants
132 discussions

Re: Issue 735 in moose-technology: OverviewPyramid raises Zero Divide

by moose-technology＠googlecode.com

Updates: Summary: OverviewPyramid raises Zero Divide Comment #4 on issue 735 by tudor.gi...(a)gmail.com: OverviewPyramid raises Zero Divide http://code.google.com/p/moose-technology/issues/detail?id=735 (No comment was entered for this change.)

11 years

Issue 772 in moose-technology: Moose Panel > ST importer > incorrect selection highlighting

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 772 by google....(a)ben.coman.com.au: Moose Panel > ST importer > incorrect selection highlighting http://code.google.com/p/moose-technology/issues/detail?id=772 Upon removing an item from a list, the next item down becomes higlighted like it is selected and the highlighting cannot be removed. It is not really selected. How to reproduce the problem: 1. Unzipped Moose Suite 4.6 Development 2. Ran Moose.app\Contents\Windows\Squeak.exe 3. WorldMenu > Moose > Moose Panel 4. Clicked the ST downarrow icon. (btw, you might think about giving the dialog that pops up a title) 5. In the [Initial list] tab selected the nine "AST-*" entries and clicked the three-right-arrows. 6. In the [Selection] tab, selected "AST-Semantic" and clicked the three-left-arrows. The row below that - "AST-Semantic-Binding" - is now highlighted as selected. 7. Try to get rid of the selection highlighting on "AST-Semantic-Binding"

11 years, 1 month

Issue 732 in moose-technology: Moose should improve the visuals for larger fonts

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Usability New issue 732 by tudor.gi...(a)gmail.com: Moose should improve the visuals for larger fonts http://code.google.com/p/moose-technology/issues/detail?id=732 The icons from GLMUIThemeExtraIcons and from MooseIcons should be saved in larger resolutions (currently, they are in 16x16). Mondrian should offer a default class variable for the size of nodes and the width of nodes and edges. These should be settable via global settings.

11 years, 1 month

Re: Issue 362 in moose-technology: Add commands to create/delete Hismo models

by moose-technology＠googlecode.com

Comment #5 on issue 362 by alexandr...(a)gmail.com: Add commands to create/delete Hismo models http://code.google.com/p/moose-technology/issues/detail?id=362 In Moose-Hismo-AlexandreBergel.57 , you can now delete an hismomodel. We need a way to create an hismo model

11 years, 1 month

Issue 666 in moose-technology: package name in DSM

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-DSM New issue 666 by jannik.l...(a)gmail.com: package name in DSM http://code.google.com/p/moose-technology/issues/detail?id=666 The package name in DSM, specially in encaps DSM are not well placed.

11 years, 1 month

Issue 621 in moose-technology: writing tests for removeMethod

by moose-technology＠googlecode.com

Status: Accepted Owner: ---- CC: cy.delau...(a)gmail.com Labels: Type-Defect Priority-Medium RPackage New issue 621 by stephane...(a)gmail.com: writing tests for removeMethod http://code.google.com/p/moose-technology/issues/detail?id=621 writing tests for "The bug appeared when removing two extensions methods (from the same extending package) for a same class. in RPackage >> removeMethod: , when removing an extension method, we were telling the organizer to remove the extending package for the class concerned. This was wrong, because even if one extension from this package has been removed, some others can still exist. And the organizer should keep the this package as extending package for the class. So removing the first extension method worked correctly, but then removing a second or more methods from the same package was raising some errors "

11 years, 1 month

Issue 527 in moose-technology: Add ModelInfo to hold extra information in MSE

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-MooseCore Milestone-4.3 New issue 527 by tudor.gi...(a)gmail.com: Add ModelInfo to hold extra information in MSE http://code.google.com/p/moose-technology/issues/detail?id=527 We should add a special MooseModelInfo entity that can be serialized in MSE. Like this we would have a backward compatible solution for storing extra information in MSE such as: - source language - importer version - metamodel version - importing date - source version I will give it a try for 4.3

11 years, 1 month

Issue 771 in moose-technology: Problem with tabs in Glamour

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 771 by santiago...(a)gmail.com: Problem with tabs in Glamour http://code.google.com/p/moose-technology/issues/detail?id=771 Running the following script: | browser | browser := GLMTabulator new. browser row: [ :r | r column: #columnA; column: #columnB ]. browser transmit to: #columnA; andShow: [ :a | a list display: [" :model | "#('Value 1' 'Value 2' 'Value 3' 'Value 1') ] ]. browser transmit from: #columnA; to: #columnB; andShow: [ :a | a list titleIcon: GLMUIThemeExtraIcons glamorousBrowse; display:#('data A' 'data B' 'data C'). a text titleIcon: GLMUIThemeExtraIcons glamorousAccept; display:'something'. a text titleIcon: GLMUIThemeExtraIcons glamorousAdd; display:'add something'. ]. browser openOn: MooseModel root allModels anyOne. after selecting a value in columnA the columnB is opened in the last tab (the one with the glamorousAdd icon). Instead it must be opened in the first tab (the one with the glamorousBrowse icon). Using text instead of icons, it works.

11 years, 1 month

Issue 658 in moose-technology: write a test for MooseMenu entries

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 658 by jannik.l...(a)gmail.com: write a test for MooseMenu entries http://code.google.com/p/moose-technology/issues/detail?id=658 We need a test that take all entries in Moose Browser and test them, to avoid DNU and other kind.

11 years, 1 month

Issue 728 in moose-technology: VerveineJ places methods in the wrong classes

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: stephane...(a)gmail.com, anquetil...(a)gmail.com, usman.bh...(a)gmail.com Labels: Type-Defect Priority-Critical Component-VerveineJ New issue 728 by tu...(a)tudorgirba.com: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 For some reason, some methods are placed in the wrong classes. I did not manage to identify a standalone case, but it looks like if we have a case like below: public class A { ... public void m() { ... x() } } public class B { public void x() { ... } } public class C { ... } we sometimes get x as belonging to class C instead of B. The interesting part is that the invocation will go from A::m() to C::x(). This is a critical issue that stops us from using VerveineJ because the information is too unreliable.

11 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev March 2012