Moose-dev March 2013

moose-dev@list.inf.unibe.ch

28 participants
207 discussions

Issue 709 in moose-technology: add Moose-Eclipse-Plugin in Moose

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 709 by jannik.l...(a)gmail.com: add Moose-Eclipse-Plugin in Moose http://code.google.com/p/moose-technology/issues/detail?id=709 I don't know if we integrate it in Moose. But we need to do something: a web page on the Moose site, with how to load it.

10 years, 8 months

Re: Issue 156 in moose-technology: The table presentation for Glamour should provide dynamic sorting and column manipulation

by moose-technology＠googlecode.com

Updates: Summary: The table presentation for Glamour should provide dynamic sorting and column manipulation Comment #14 on issue 156 by tudor.gi...(a)gmail.com: The table presentation for Glamour should provide dynamic sorting and column manipulation http://code.google.com/p/moose-technology/issues/detail?id=156 (No comment was entered for this change.)

10 years, 8 months

Re: Issue 254 in moose-technology: inFusion default initializer export to MSE

by moose-technology＠googlecode.com

Updates: Labels: -Component-Tools Component-ExternalTools Comment #1 on issue 254 by tudor.gi...(a)gmail.com: inFusion default initializer export to MSE http://code.google.com/p/moose-technology/issues/detail?id=254 (No comment was entered for this change.)

10 years, 8 months

minimap in Glamour-Roassal

by Usman Bhatti

Hello, I am trying to create a roassal minimap in a glamour browser. But I do not get a minimap when pressing m key. It might be something to do with how keystrokes are interpreted in Glamour. can you have a look? Here's a simple browser with a roassal visualization (adapted from one of ben's mail on moose-dev). | browser viewHack | browser := GLMTabulator new. browser column: #list; column: #drawing. browser transmit to: #list; andShow: [ :a | a list ]. browser transmit to: #drawing; andShow: [ :a | a roassal painting: [ :moview :collection | moview raw @ (ROMiniMap new targetView: moview stack). collection do: [ :x | moview view add: (ROElement spriteOn: x) + ROLabel + ROBox white ]. ROVerticalLineLayout on: moview view elements. viewHack := moview view. ] ]. browser transmit from: #list port:#selection; to: #drawing; transformed: [ :x | | foundElements | viewHack elements do: [ :el | ROUnhighlightElement on: el ]. targetElement := viewHack elements at: x. ROFocusView on: targetElement. ROHighlightElement on: targetElement color: Color red. viewHack signalUpdate ]. browser openOn: #(1 2 3 4 5 6).

10 years, 10 months

Re: Issue 113 in moose-technology: Roassal should support lazy edges when used through the Mondrian API

by moose-technology＠googlecode.com

Updates: Summary: Roassal should support lazy edges when used through the Mondrian API Status: Labels: -Component-Mondrian Component-Roassal Comment #10 on issue 113 by tu...(a)tudorgirba.com: Roassal should support lazy edges when used through the Mondrian API http://code.google.com/p/moose-technology/issues/detail?id=113 No, it does not. But, it should. The idea is that the following Mondrian script should work: view edge: #edge from: 1 to: 2. view node: 1. view node: 2. For this, the edge creation should be evaluated only after all nodes are created. I changed the entry title and labels.

10 years, 10 months

Issue 690 in moose-technology: Change the font size of labels in a chart

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-EyeSee New issue 690 by andreho...(a)gmail.com: Change the font size of labels in a chart http://code.google.com/p/moose-technology/issues/detail?id=690 Change the font size of labels in a chart using #defaultFontSize: is not working.

10 years, 11 months

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

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 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, 1 month

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev March 2013