Moose-dev August 2013

moose-dev@list.inf.unibe.ch

26 participants
167 discussions

Issue 900 in moose-technology: Glamour-Roassal should be able to work with raw ROView not just ROMondrianBuilder

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 900 by benjamin...(a)gmail.com: Glamour-Roassal should be able to work with raw ROView not just ROMondrianBuilder http://code.google.com/p/moose-technology/issues/detail?id=900 Hopefully, I've cracked this. In response to my own query: "Could something like a GLMMorphicRoassalRawRenderer be added to the Glamour-Roassal interface? - which would pass an unencumbered ROView to the paintingBlock. It is not really a Glamour-Roassal interface at the moment, more of a Glamour-Mondrian interface." With the attached slice you can now go... browser transmit to: #graphic andShow: [ :a | a roassal newView: [ ROView new @ RODraggable ] ; painting: [:view :input | view add: ROElement new] ]. After loading you can first try the new & old tests in 'Glamour-Tests-Roassal' then try 'GLMRawRoassalExamplesBrowser open' I surprised myself that I got this far. A few times I hit a brick wall and was going to submit a half done proof-of-concept, but then just kept digging. Apart from hopefully getting integrated, some critical feedback would appreciated. A few points for review... 1. I had considered using #viewPrototype: with an instance to copy, but then I wasn't sure how deep I should copy it to produce a new view. So using a block with newView: seemed the safer path (and it also feels like it opens up some interesting possibilities, even if I can't think what they are at the moment) 2. I noticed that GLMRoassalPresentation>>renderOn: had a flag 'This should be the responsibility of the view'. This method was one that I previously copied and modified for GLMRoassalRawPresentation in my "Interactive Roassal" experiment. There I removed the calls to #applyLayout and #populateMenuOn since these were MNU for ROView (which had replaced ROMondrianViewBuilder). This time I pushed these two calls into ROMondrianViewBuilder>>preOpen, where ROView>>preOpen is left empty. I'm note sure I'm happy with #preOpen as a name but it was the best I could come up with, since I also refactored ROMondrianViewBuilder>>open to use it. 3. GLMMorphicRoassalRenderer>>render: had hardcoded reference to #stack with "ROMorph on: view stack" so I pushed the required difference into ROMondrianBuilder>>newMorph and ROView>>newMorph. 4. GLMMorphicRoassalRenderer>>actOnPresentationUpdate had hardcoded use of #stack in "setView: aView stack" so I pushed that into ROMondrianViewBuilder>>onMorph: and ROView>>onMorph: 5. GLMMorphicRoassalRenderer>>actOnPresentationUpdate had hardcoded ROMondrianViewBuilder so I modified this to use the block passed to GLMRoassalPresentation>>newView: . 6. I copied GLMRoassalMorphicTest to GLMRawRoassalMorphicTest with required modifications. 7. I copied GLMRoassalExamplesBrowser to GLMRawRoassalExamplesBrowser with required modifications.

11 years, 5 months

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, 5 months

Issue 918 in moose-technology: GLMTreePresentation display artifact when selection is set to an unexpanded node

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 918 by benjamin...(a)gmail.com: GLMTreePresentation display artifact when selection is set to an unexpanded node http://code.google.com/p/moose-technology/issues/detail?id=918 Execute the following Workspace script, then in the left pane, click on $X while it is not expanded. An display artifact appears on the first line as shown in attached image, which is the an overlap of the the hidden third level $X and $O. See attached PNG. Also the right pane locks up, which can be reset by unexpanding $A. If you expand the $X in the right pane before clicking the $X in the left pane, the problem does not occur. --- |browser | browser := GLMTabulator new. browser column: #one; column: #two. browser transmit to: #one; andShow: [ :a | a tree rootsExpanded; children: [:x :i | x asString size > 1 ifTrue: [x] ifFalse: [OrderedCollection new] ] ; format: [ :x | x isCollection ifTrue: [x first] ifFalse: [x] ]. ]. browser transmit to: #two; andShow: [ :a | a tree rootsExpanded; children: [:x :i | x asString size > 1 ifTrue: [x] ifFalse: [OrderedCollection new] ] ; format: [ :x | x isCollection ifTrue: [x first] ifFalse: [x] ]. ]. browser transmit from: #one; to: #two port: #selection. browser openOn: #(($A $B ) ($C $E ($X $O))) Attachments: GLMTreePresentation-artifact.png 9.6 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

11 years, 6 months

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, 6 months

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, 6 months

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, 6 months

Issue 923 in moose-technology: EyeSee red-square-of-death from ESValueLabelDecorator>>chooseNonOverlappingValues

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 923 by benjamin...(a)gmail.com: EyeSee red-square-of-death from ESValueLabelDecorator>>chooseNonOverlappingValues http://code.google.com/p/moose-technology/issues/detail?id=923 ESValueLabelDecorator>>chooseNonOverlappingValues has the line... chosenValues add: (self values minValue: [:each | each value]). but minValue: injects (Float infinity) so that if 'self values' is empty then (Float infinity) is added to choseValues, which later are #rounded causing an error in the Morph drawing and subsequent RSOD for the EyeSee morph. I am not sure if I've done something wrong that causes 'self values' to be empty, but in any case, this should not kill the Morph. Just for further information, here is the triggering code... browser transmit from: #navigationtree; to: #attributes; andShow: [ :a | a eyesee title: 'Optimize' ; diagram: [ :renderer :input | renderer scatterplot diagramTitle: '@', input absorbedLoad asString , 'kW' ; x: #ratedOutput ; y: [ :m | m powerLossForAbsorbedLoad: input absorbedLoad ] ; valueAxis ; addXDecorator: ESValueLabelDecorator new ; models: (LEKCatalogMotor catalog values sort: [ :m1 :m2 | m1 ratedOutput < m2 ratedOutput ]). ]. where if in a Workspace I do... models:= (LEKCatalogMotor catalog values sort: [ :m1 :m2 | m1 ratedOutput < m2 ratedOutput ])'. models collect: [ :m | m ratedOutput -> m powerLossForAbsorbedLoad: 24 ] explore ...then all the data looks okay. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

11 years, 6 months

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, 6 months

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, 6 months

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, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev August 2013