Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Maintainability Milestone-4.4
New issue 575 by tudor.gi...(a)gmail.com: Filesystem does not load
http://code.google.com/p/moose-technology/issues/detail?id=575
The Filesystem package is now empty and its contents have been moved to
sub-packages. Also, the new repository is squeaksource.com/fs
The problem is that ConfigurationOfFilesystem is not updated, so we first
need to fix this and then add it to the ConfigurationOfMoose.
Hi,
I noticed that Filesystem changed significantly recently both internally and in package structure (I guess it was Colin - the user says cwp). This led to some red tests in Moose that I now fixed. I am writing here to document these changes in case other people are using this nice library.
>From a package point of view Filesystem has now a cool structure with basically each category being in a separate package. Furthermore, the original Filesystem is now empty which might create problems if people are loading it like we do in Moose.
To get it loading, I created a new baseline (2.0.1-baseline) in the ConfigurationOfFilesystem.
There were also some refactorings at the level of the model. Now, FSFilesystem does not have subclasses anymore (e.g., FSDiskFilesystem does not exist anymore). Instead there is a composition with a Store, so you will have FSDiskStore.
Thus, if before you used something like "FSDiskFilesystem current", now you will have to use "FSDiskStore currentFilesystem"
That was it.
Everything is green now in Moose land.
Cheers,
Doru
--
www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Hi,
There are some cool things happening around Moose these days:
- EyeSee is almost fully working in Pharo thanks to the port of Andre, and it is now in the ConfigurationOfMoose
- Glamour is on the way to receive a Wizard and dialog ability thanks to the work of Cyrille
- Nicolas is doing a nice job on VerveineJ
- Alex and Vanessa improved significantly the tests of Moose
- Alex improved Mondrian to better render complex shapes
- Igor and Ben are working on the basic Pharo widgets which will boost the Glamour capabilities
- Fabrizio is working on parsing SQL
- I worked on Metanool
- I extended the Finder was with several views like the DSM, or the dependencies, and I worked on improving the bookmarking behavior
I might have missed something, but I really like this rhythm. Let's keep it :)
Cheers,
Doru
--
www.tudorgirba.com
"Be rather willing to give than demanding to get."
Status: New
Owner: ----
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Mondrian Milestone-4.4
New issue 572 by tudor.gi...(a)gmail.com: Nodes with complex shapes do not
move with the parent node
http://code.google.com/p/moose-technology/issues/detail?id=572
Try the following code and then try to drag and drop the top node.
view node: 'hello' forIt: [
view shape umlClass.
view nodes: (1 to: 5).
view verticalLineLayout
]
You will see that the inner nodes look like they remain in the same place.
However, clicking works well, which means that the bounds of the children
nodes are computed correctly. Only the drawing is somewhat strange.
Hi Andre,
I saw that your last commits say that the labels should be rotatable now. However, in the latest Moose image based on 1.2.1, it does not seem to work. Am I doing something wrong?
Cheers,
Doru
--
www.tudorgirba.com
"What we can governs what we wish."
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-Finder Milestone-4.4
New issue 573 by tudor.gi...(a)gmail.com: DSM should be integrated into Moose
Finder
http://code.google.com/p/moose-technology/issues/detail?id=573
DSM should be shown as a separate tab in the MooseFinder for namespaces and
packages
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Milestone-4.4
New issue 565 by tudor.gi...(a)gmail.com: Implement Metanool bridge between
Fame and Magritte
http://code.google.com/p/moose-technology/issues/detail?id=565
Metanool was a VW project to provide editing of Moose entities properties.
Moose entities provide Fame descriptions. To make them editable, we can use
Magritte.
Hi,
i got a strange behaviour from Mondrian trying to build a shape for data base tables. Basically defining a shape which contains a rectangle with a title and a children shape it happen that the rectangle containing the title have the same size of the children shape. Is it a bug or is a problem of my code? Below the code that i use, copy and paste in MOShapeSelector the tableShape method and than in a normal mondrian easel window you should be able to reproduce the same behaviour with the snippet below.
By using this shape definition:
tableShape
| builder |
builder := MOFormsBuilder new.
builder column; fill; pref; grow.
builder row; fill; pref; grow; row; fill; pref; grow.
builder x: 1 y: 1 add: (MORectangleShape new text: [:table | table name]; fontSize: 10).
builder x: 1 y: 2 add: MORectangleShape new.
builder x: 1 y: 2 add: MOChildrenShape new.
^view shape: builder shape
and using this visualization script:
view shape tableShape.
view node: (FAMIXNamedEntity new name: 'test') forIt: [
view shape rectangle.
view nodes: (1 to: 20).
view verticalLineLayout. ].
I got the result in the attachment.
Thanks,
Fabrizio
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 498 by fabrizio...(a)gmail.com: the sizes of the rectangles into
built shape are the same
http://code.google.com/p/moose-technology/issues/detail?id=498
Defining a shape which contains a rectangle with a title and a children
shape it happen that the rectangle containing the title have the same size
of the children shape while i would expect that the rectangle size was
coherent with its content.
By executing the following code in Mondrian you will see the problem
| builder |
builder := MOFormsBuilder new.
builder column; fill; pref; grow.
builder row; fill; row; fill; pref; grow.
builder x: 1 y: 1 add: (MORectangleShape new text: [:table | table name];
fontSize: 10).
builder x: 1 y: 2 add: MORectangleShape new.
builder x: 1 y: 2 add: MOChildrenShape new.
view shape: builder shape.
view node: 'hello' forIt: [
view nodes: (1 to: 5).
view verticalLineLayout
]
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.4
New issue 568 by tudor.gi...(a)gmail.com: EnumValue should be a
StructuralEntity
http://code.google.com/p/moose-technology/issues/detail?id=568
From Nicolas:
Why is EnumValue not a StructuralEntity ? (it is a NamedEntity)
From http://download.oracle.com/javase/tutorial/java/javaOO/enum.html
"An enum type is a type whose fields consist of a fixed set of constants."
they are considered fields in Java ...
I just realized Verveine does not export access to enumValues.
But with the meta-model I have (bare 4.3), it seems an access to an
enumValue is an invocation.
This is counter intuitive.