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.
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
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.
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 "
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
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 658 by jannik.l...(a)gmail.com: write a test for MooseMenu entries
http://code.google.com/p/moose-technology/issues/detail?id=658
We need a test that take all entries in Moose Browser and test them, to
avoid DNU and other kind.
Status: New
Owner: ----
CC: stephane...(a)gmail.com, anquetil...(a)gmail.com, usman.bh...(a)gmail.com
Labels: Type-Defect Priority-Critical Component-VerveineJ
New issue 728 by tu...(a)tudorgirba.com: VerveineJ places methods in the
wrong classes
http://code.google.com/p/moose-technology/issues/detail?id=728
For some reason, some methods are placed in the wrong classes.
I did not manage to identify a standalone case, but it looks like if we
have a case like below:
public class A {
...
public void m() { ... x() }
}
public class B {
public void x() { ... }
}
public class C { ... }
we sometimes get x as belonging to class C instead of B. The interesting
part is that the invocation will go from A::m() to C::x().
This is a critical issue that stops us from using VerveineJ because the
information is too unreliable.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 704 by alexandr...(a)gmail.com: One click image has a squeak icon
http://code.google.com/p/moose-technology/issues/detail?id=704
Apparently, the icon of the one-click image available form Moose;s jenkins
is the Squeak one.
Updates:
Labels: Component-SmalltalkImporter
Comment #4 on issue 435 by tudor.gi...(a)gmail.com: Using RoelTyper for a
better precision of method invocation
http://code.google.com/p/moose-technology/issues/detail?id=435
It seems that RoelTyper does not work for all classes. Try this code for
getting the classes that raise an error:
classes := Dictionary new.
Object withAllSubclassesDo: [:each |
[(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error |
classes at: each put: error ]].
classes inspect
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 516 by tudor.gi...(a)gmail.com: System Complexity displays more
than the classes in the group
http://code.google.com/p/moose-technology/issues/detail?id=516
Currently, the algorithm to identify the hierarchies does not limit the
result to the current class group, but it takes all the subclasses of the
superclass. This means that if you have a group with Object inside, you
will end up with a system complexity with all classes.