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
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 1077 by damien.c...(a)gmail.com: System complexity is not
interactive
http://code.google.com/p/moose-technology/issues/detail?id=1077
The system complexity visualisation is not interactive: I don't get any
fly-by-help nor can I click on rectangles to have details about the class.
--
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
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 1070 by damien.c...(a)gmail.com: Group 'UI' depends on PPBrowser
without loading it
http://code.google.com/p/moose-technology/issues/detail?id=1070
Execute this in Pharo 3:
(ConfigurationOfMoose project version: #development) load: 'UI'
Then you can't open the World menu anymore. PPBrowser is missing.
--
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
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.
I’m trying to use Moose to analyze some C++ and Java code and will need some advice. First, I’ve tried to parse the Java code with inFamix and continue to get the error “The location of the project must be specified.” I’ve passed in as ‘-path’ every directory down to a Main.java file.
James
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
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 1076 by damien.c...(a)gmail.com: System complexity can't export as
PNG
http://code.google.com/p/moose-technology/issues/detail?id=1076
When viewing the system complexity visualization, clicking on "Export as
PNG" under the black triangle opens a debugger: ROAthensImageExporter has
the sublcass responsability to implement exportViewAsPNG:
--
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
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-GlamorousToolkit
New issue 1085 by alexandr...(a)gmail.com: tool tip in the Playground
http://code.google.com/p/moose-technology/issues/detail?id=1085
Describe the problem: what do you get? what do you expect?
If I put the mouse above the play icon, top right of a window. The
keybinding (cmd-o) may be indicated no?
--
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
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
Status: New
Owner: ----
Labels: Type-Defect Priority-Critical
New issue 1034 by alexandr...(a)gmail.com: Glamour easel and GTDebugger
http://code.google.com/p/moose-technology/issues/detail?id=1034
Hi!
I have spotted an important bug. If I enter the following in the Glamour
Roassal easel:
view nodes: (1 to: 20).
self halt.
A debugger is open, but I cannot step in. Apparently the code source is not
accessible. This is a major regression...
--
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