Moose-dev November 2013

moose-dev@list.inf.unibe.ch

31 participants
160 discussions

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

9 years, 5 months

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.

9 years, 5 months

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

9 years, 5 months

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.

9 years, 5 months

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

9 years, 5 months

Roassal on the web

by Usman Bhatti

Hi Alex, Any updates of the project about constructing visualizations with Roassal for the web (with Amber?)? Did that project get accepted for GSoc? If not, do you plan to have a version of Roassal that could allow scripting visualizations on the web (with Seaside)? Because soon we'll need it ;). regards, usman

9 years, 8 months

Issue 1015 in moose-technology: GraphET should support lineWidth and legend

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1015 by usman.bh...(a)gmail.com: GraphET should support lineWidth and legend http://code.google.com/p/moose-technology/issues/detail?id=1015 Graphet should provide support for line width for line diagrams and a legend. -- 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

9 years, 8 months

Re: Issue 228 in moose-technology: Nested browsers do not take "when", or "display" into account

by moose-technology＠googlecode.com

Updates: Labels: -Milestone-4.2 Comment #4 on issue 228 by tudor.gi...(a)gmail.com: Nested browsers do not take "when", or "display" into account http://code.google.com/p/moose-technology/issues/detail?id=228 (No comment was entered for this change.)

9 years, 9 months

Re: Issue 995 in moose-technology: Roassal does not export the full PNG / SVG

by moose-technology＠googlecode.com

Updates: Summary: Roassal does not export the full PNG / SVG Comment #6 on issue 995 by tu...(a)tudorgirba.com: Roassal does not export the full PNG / SVG http://code.google.com/p/moose-technology/issues/detail?id=995 (No comment was entered for this change.) -- 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

9 years, 9 months

Issue 757 in moose-technology: Smalltalk completion appears at absolute coordinates, instead of relative ones in Finder

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Glamour New issue 757 by tudor.gi...(a)gmail.com: Smalltalk completion appears at absolute coordinates, instead of relative ones in Finder http://code.google.com/p/moose-technology/issues/detail?id=757 Try this: GLMFinder new show: [:a | a smalltalkCode ]; openOn: ''. and then type "1 as". You will see that the completion appears in the top right of the world, instead of the top right of the text pane. This only happens in the finder, and it is likely due to some problems of transforming coordinates.

9 years, 9 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2013