February 2014 - Moose-dev

Issue 981 in moose-technology: Glamour should provide a means to not transmit all Roassal clicks

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-5.0 New issue 981 by tu...(a)tudorgirba.com: Glamour should provide a means to not transmit all Roassal clicks http://code.google.com/p/moose-technology/issues/detail?id=981 Originally reported on stackoverflow: http://stackoverflow.com/questions/18829093/make-edges-not-clickable-in-r... In the below example, you need to uncomment the two lines to work around this issue. We need a better solution. browser := GLMTabulator new. browser column: #myRoassal ; column: #mySelection. browser transmit to: #myRoassal ; andShow: [ : aGLMPresentation | aGLMPresentation roassal painting: [ : view : numbers | |edges| view shape rectangle ; withText ; size: 30. view nodes: numbers. view interaction noPopup. view edges: numbers from: [ :x | x / 2] to: [ :x | x ]. " view edges do: [ :edge | edge model:#doNotSelectMe ]." view treeLayout. ]. ]. browser transmit to: #mySelection ; from: #myRoassal ; " when: [ :selection | selection ~= #doNotSelectMe ] ;" andShow: [ : aGLMPresentation | aGLMPresentation text display: [ : selectedItem | selectedItem asString ] ]. browser openOn: (1 to: 10). -- 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

8 years, 10 months

1
1
0 / 0

Re: Issue 890 in moose-technology: All meta-entities should have a class comment

by moose-technology＠googlecode.com

Updates: Summary: All meta-entities should have a class comment Comment #1 on issue 890 by tu...(a)tudorgirba.com: All meta-entities should have a class comment http://code.google.com/p/moose-technology/issues/detail?id=890 (No comment was entered for this change.)

8 years, 10 months

1
4
0 / 0

Issue 816 in moose-technology: MooseMetaBrowser's Map re-display after selection of a node

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-MooseCore New issue 816 by anquetil...(a)gmail.com: MooseMetaBrowser's Map re-display after selection of a node http://code.google.com/p/moose-technology/issues/detail?id=816 In the Moose MetaBrowser, when selecting a node in the Map, this map is redisplayed at a new location which can even hide the selected node. How to reproduce the problem: - open MetaBrowser - the map (drawing) must be larger than the Map panel - scroll to the right of the map - select a node (at the right) - the map is redisplayed scrolled back to its initial position (full left) Same thing happens vertically (scroll down, select a node down, map is redisplayed from top)

8 years, 10 months

1
10
0 / 0

Issue 1003 in moose-technology: The treemap builder should offer a default weight of 1

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Roassal Milestone-5.0 New issue 1003 by tu...(a)tudorgirba.com: The treemap builder should offer a default weight of 1 http://code.google.com/p/moose-technology/issues/detail?id=1003 Right now, the weight block has to be specified. Instead, we should have a default weight of 1. Furthermore, right now, if the weight returns 0 (like above), we get a ZeroDivide. Zero should be handled without an error. -- 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

8 years, 10 months

1
2
0 / 0

Re: Issue 674 in moose-technology: Bullet graphs in Graph-ET

by moose-technology＠googlecode.com

Updates: Summary: Bullet graphs in Graph-ET Labels: -Component-EyeSee Comment #2 on issue 674 by tu...(a)tudorgirba.com: Bullet graphs in Graph-ET http://code.google.com/p/moose-technology/issues/detail?id=674 I changed the topic to be related to Graph-ET :) -- 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

8 years, 10 months

1
1
0 / 0

Issue 514 in moose-technology: Introduce the PharoImageSourceAnchor

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-SmalltalkImporter Component-Famix New issue 514 by tudor.gi...(a)gmail.com: Introduce the PharoImageSourceAnchor http://code.google.com/p/moose-technology/issues/detail?id=514 Currently, FAMIXClass>>sourceText has a hack that checks for mooseModel isSmalltalk explicitly. We should introduce a PharoImageSourceAnchor that properly takes care of this.

8 years, 10 months

1
1
0 / 0

Issue 973 in moose-technology: Roassal font organizer singleton inconsistencies

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 973 by benjamin...(a)gmail.com: Roassal font organizer singleton inconsistencies http://code.google.com/p/moose-technology/issues/detail?id=973 Following on from Issue 971, use of singletons related to the Roassal font organizer seems not used consistently. Using Finder, I've searched all 'Source' of Roassal packages, for the following both 'ROFontOrganizer' and 'fontOrganizerClass' and found... ----Part1-------------- ROAbstractLabel >> fontFor: anElement with: aCamera fo := ROPlatform current fontOrganizerClass. ROAbstractLabel >> offsetWhenDrawing ^ ROPlatform current fontOrganizerClass ROAbstractLabel >> widthOfLine: string withFont: aFont ^ ROFontOrganizer current widthOfString: string font: font. I propose the last is changed to... ROAbstractLabel >> widthOfLine: string withFont: aFont ^ ROPlatform current fontOrganizerClass widthOfString: string font: font. and also delete... ROFontOrganizer >> current ^ self subclasses first which seems plain wrong. ----Part2-------------- Also I'm a perplexed by the way both of these methods ROMorphicPlatform>>fontOrganizerClass ^ ROFontOrganizerMorphic ROPharoAthensPlatform>>fontOrganizerClass ^ ROFontOrganizerAthens override this one ROPlatform>>fontOrganizerClass ^ fontOrganizerClass such that the instance-variable 'fontOrganizerClass' is ignored, as well as the following seeming irrelevant... ROPlatform>>fontOrganizerClass: ^ fontOrganizerClass := aClass. Is ROPlatform ever instantiated, or abstract? A search for all references to 'ROPlatform' in the 'Source' of all Roassal finds... * ROPlatform current (x40) * ROPlatform platforms (x2) * ROPlatform removeNamed: (x1) * ROPlatform add: (x2) * ROPlatform setCurrent: (x1) * ROPlatform new (x1) The last is only in a test ROPlatformTest>>testAddingAPlatform. I propose to modify... ROPlatform>>fontOrganizerClass self subclassResponsibility delete.... fontOrganizerClass instance-variable delete... ROPlatform>>fontOrganizerClass: from... ROPlatformTest>>testAddingAPlatform remove line... platform fontOrganizerClass: ROFontOrganizer subclasses anyOne. hope this helps, cheers -ben -- 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

8 years, 10 months

1
5
0 / 0

Issue 528 in moose-technology: Remove Category Importer

by moose-technology＠googlecode.com

Status: Accepted Owner: ---- Labels: Type-Defect Priority-Medium Milestone-4.3 Component-Famix Component-SmalltalkImporter New issue 528 by jannik.l...(a)gmail.com: Remove Category Importer http://code.google.com/p/moose-technology/issues/detail?id=528 With RPackage, Category importer is useless, We should remove it. They are some referecnes in examples in DSM.

8 years, 10 months

1
6
0 / 0

Issue 1002 in moose-technology: The treemap builder should support multiple types of nodes

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal Milestone-5.0 New issue 1002 by tu...(a)tudorgirba.com: The treemap builder should support multiple types of nodes http://code.google.com/p/moose-technology/issues/detail?id=1002 TreeMaps are particularly useful to show leaf nodes within a nested parent nodes tree. For example, they can show classes within packages. They are less useful for showing only one type of nodes, like a class hierarchy given that the weight is only meaningful when applied to the leaf nodes. However, right now, we can specify nodes only with one block, weight with one block only and edges with another one block. This is less convenient. We should extend this to allow multiple sets of nodes. Consider this code: packages := RPackageOrganizer default packages select: [:each | each name beginsWith: 'AST']. classes := packages flatCollect: [:each | each definedClasses ]. ... builder weightBlock: [ :el | el isBehavior ifTrue: [ el linesOfCode + 1] ifFalse: [ 1 ] ]. builder nodes: (packages), (classes). builder nestingFromAssociations: ( (builder nodes select: [ :each | each isBehavior ]) collect: [ :each | (each) -> each package ]). builder drawOn: rawView . It would be better to have it like: builder weight: [ :el | el linesOfCode + 1] ]. builder nodes: classes. builder nodes: packages builder nest: classes in: [ :each | each package ]. builder drawOn: rawView . Note how nesting is defined following the same pattern as edges:from:to:, and how the weight is only applied to the next nodes. -- 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

8 years, 10 months

1
1
0 / 0

Issue 1044 in moose-technology: Can't debug block local variables in GT debugger

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1044 by v.blonde...(a)gmail.com: Can't debug block local variables in GT debugger http://code.google.com/p/moose-technology/issues/detail?id=1044 Describe the problem: what do you get? what do you expect? In the GT Debugger, when you debug a block with a local variable; you can't read its value because the variable is unknown... How to reproduce the problem: step by step if necessary Write in a Workspace : 1 = 1 ifTrue: [ |local | local := 1 ] Debug It! Use the through button to go into the block. Try to inspect the local variable. Additional information: platform, context which may impact the problem Moose 5.0 latest - Ubuntu 13.10 - x64 Please fill in the labels with the following information: * Type-Defect * Component-GT-Debugguer * Milestone-5.0 -- 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

8 years, 11 months

1
4
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev February 2014